XInput extension, xf86XInput, evdev and a spaceball

[Peter Hutterer]

On Mon, Aug 31, 2009 at 04:53:51PM +0200, Steffen Seeger wrote:
> Hi again,
> 
> On Sunday 30 August 2009 18:08:08 Daniel Stone wrote:
> > 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.
> 
> FC11 comes with server 1.6 and evdev 2.2 (minors are in the patch provided).
> I have tried also FC12 alpha, which comes with xorg-server-1.6.99 and
> xorg-drv-evdev-2.2.99.
> 
> > On Sunday 30 August 2009 18:08:08 Daniel Stone wrote:
> > > > 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.
>  
> Both plain FC11 and plain FC12 have essentially the same behaviour:
> device is listed via "xinput --list", but moves the core pointer with its 
> x and y axes. Grabbing the device makes no difference in behaviour.
> 
> On FC12, floating the device behaves more closely to what 
> one would expect, but strange valuator values get reported.
> It seems as if the server gets incremental updates (e.g. some events
> like 'axis 3 and 5 have new values') and reports only changed valuators
> correctly and others as 0x8000000. Investigating this with repeated
> "xinput query-state" and "kcmshell4 joystick" running in parallel 
> crashed the server for some unknown (but probably related) reason.
> I was not able to reproduce this, but have not tried very hard either.
> 
> So thanks to everybody who responded, I suggest I will wait until FC12
> is fully released and then investigate further and file a full bug report.

please file the bugreport now. things don't get magically fixed just because
we bump the version number. they only get fixed when people file bugs
_before_ the bump happens.  F12 is close enough to upstream so please file
at bugs.freedesktop.org and assign it to me.

Please download http://people.freedesktop.org/~whot/evtest.c, compile it
with gcc -o evtest evtest.c and then run it as root against the device file.
The device file is /dev/input/eventX, where X is a number. You can get the
right device file by looking into /proc/bus/input/devices. 
Then attach the output to the bugreport. I can write a virtual device based
on that info that should replicate the bug on my side.

Cheers,
  Peter