XInput extension, xf86XInput, evdev and a spaceball

Daniel Stone daniel at fooishbar.org
Sun Aug 30 09:08:08 PDT 2009


Hi,

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.

> 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.

> 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.

> 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.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20090831/aca5b95c/attachment.pgp 


More information about the xorg-devel mailing list