XInput extension, xf86XInput, evdev and a spaceball

[Peter Hutterer]

On Mon, Aug 31, 2009 at 02:08:08AM +1000, Daniel Stone wrote:
> On Sun, Aug 30, 2009 at 02:28:37PM +0200, Steffen Seeger wrote:
> > I want to use it via the XInput extension, as this seems the best
> > way to stay OS independent. I got it working somehow, but trying 
> > to sort out the last issues I got stuck somewhere between the evdev
> > driver, XInput extension and dix layer.
> > 
> > The evdev layer is working, the device gets detected and 'kcmshell4 joystick'
> > shows the valuator and button states as expected. Handing some magic
> > configuration potion to haldaemon made the evdev driver recognize the
> > device as well.
> 
> Which versions of everything are you using? xserver + xf86-input-evdev
> from git master (which is destined to become 1.7 in Septemberish) should
> work fine over XInput2.  If not, please file a bug and we (by which I
> really mean Peter) will get fixed.

fwiw, fedora 11 has server 1.6 + evdev 2.2.

> > However, my problem is that the device gets reported (and used) as
> > XExtensionPointer device, which is not how you typically use that device.
> > The effect is that moving the spaceball you control the valuators
> > of the XInput device, but also the core pointer position.
> 
> Depends on how you map the axes.  I guess a 'map tilt to x/y' property
> might be useful, since some people really want to use it as a pointer,
> while others don't.

working on it. see http://bugs.freedesktop.org/show_bug.cgi?id=21129

> > This moves the core pointer, the core pointer sprite and possibly focus
> > to the center of the screen each time the spaceball is touched.
> > Also, the spaceball is not reported as a XI_SPACEBALL type device
> > as applications might expect. I got around this problem with some
> > minor if's and else's in the evdev driver, mainly stripping
> > XI86_POINTER_CAPABLE from pInfo->flags.
> > With those modifications in the evdev driver, the core pointer doesn't
> > move any longer, but the events still get posted as core pointer motion
> > events (it just decouples motion of the pointer sprite from 
> > valuator position).
> 
> Does this go away if you go through the list of input devices (note:
> requires XI2) and grab the slave device? When you do that, at least in
> current master, the Spaceball will get detached from the core pointer
> and stop moving it.

for a device like that it is better to permanently float it. xinput --float
"my device name" does the trick. Once the device is floated, it can only be
accessed by XI applications and it won't control the pointer.
caveat: there's no configuration option, you have to do it at runtime.

this is essentially the trick you need, once the device is floated it should
be accessible and not moving the core pointer. if the axes don't get
reported properly then that's a definitive bug.
 
> > After some investigation found this to be possibly due some strange and
> > possibly inconsistent heuristics in dix/events.c:IsPointerDevice() and
> > Xi/listdev.c:CopySwapDevice().  Everything with valuators and buttons
> > is considered as a PointerDevice (either core or extended).
> 
> Indeed.
> 
> > Changing that assumption to consider only devices with two valuators and
> > buttons as PointerDevice and making consistent use of IsPointerDevice().
> > made indeed the spaceball appear as XExtensionDevice.
> > [Note: Don't know how this change affects touchpads with pressure evaluation].
> 
> Yeah, this will break touchpads, touchscreens, tablets, etc.
> 
> > But: No valuator events are reported.
> > 
> > The reason seams to be that the evdev input driver properly collects the
> > valuator state and calls
> > 	hw/common/xfree/xf86Xinput.c:xf86PostMotionEventsP()
> > which finally calls 
> > 	dix/getevents.c:GetPointerEvents()
> > which does not seem to care about valuator only devices (but
> > somehow scales axis x and y to have screen coordinates).
> 
> That should come under MotionNotify, but even ButtonPress events will
> copy over the whole set of valutors to the Xi event.  Specifically, it
> will report a Device{MotionNotify,{Key,Button}{Press,Release} event
> with a trailing DeviceValutor event, which should include the entire
> valutor state.

yes, but don't forget that inside the server we use internal events now. so
you don't see the actual DeviceMotionNotify + DeviceValuator in the server
until quite late.

Cheers,
  Peter