input-evdev patch adding option to override XDevice type Atom, option to force EV_REL events being treated as absolute values.

[Wolfgang Draxinger]

Am Dienstag, 11. März 2008 schrieb Ville Syrjälä:

> Perhaps a quirk in the usbhid driver to fix up the events would be
> better. Unless there is some valid reason for interpreting the
> events as relative.

That's usbhid design, it's meant to be plain stupid: It just passes on 
what the devices send to it. Also it would require people to install 
the most recent Linux kernel if they needed this quirks mode. The X 
server is more likely to be updated than the kernel IMHO. Maybe a 
parallel approach is the way to go: Support it in both the kernel and 
evdev in one way or another.

But there has another problem I had not thought of yet. Some (most) 
relative devices don't send a 0-vector if they go into neutral state. 
Which means that there remains a non-null absolute value even if the 
device has gone neutral. In case of a spaceball this means that the 
program will continue applying the very last transformation 
constantly (usually one reads the absolute values of a spaceball and 
integrates them over time within a in client loop). Admittingly such 
programs could just put the device into relative mode and set the 
valuators to 0 some timeout after the last MotionEvent. But being 
able to set the valuators requires the device being Absolute capable. 
At least using XSetValuators caused a BadRequest (IIRC) when I tried 
it on the then relative-only spaceball device.

The obvious solution would be a timeout, that implicitly sets the 
valuators to 0 if no further events came in after a EV_SYN for a 
given period of time (100ms or so). However I have no elegant idea, 
how to implement a timeout within a XInput driver. First I tried to 
play around with timeouts in the Read callback, but is just caused 
MotionEvents to accumulate and get sent out in a batch once the 
device has gone neutral... OTOH this was the first time I hacked the 
server part of X.Org, I bet there's a way for a module to install a 
timeout function.

Anyway I think that there sould be the possibilty to treat relative 
devices as absolute valuators, this can be very usefull, even for 
devices, that are purely relative. E.g. you can use a optical mouse 
as a speed sensor: In relative mode you've to warp the pointer when 
it hits the screen edges. But in absolute mode the values you get are 
the speed. Or think about games. Until now the pointer has to be 
warped if it hits the window or screen edges. If the mouse were 
absolute and un-cored this wouldn't be neccesary. I really wonder why 
the MotionEvent structure has no field that gives you the raw data 
(i.e. in absolute mode just the values and in relative mode the 
delta). Then client programs could use this data without bothering 
about the mode the device is in, just as they see fit.

Nevertheless the ForceType option is mandatory, if we want to inform 
clients about the type of device, since evdev has no crystal ball 
built in and the USB-HID protocoll won't tell us. Either add some 
device database and/or have this option.

Well, this has been my attempt on this problem. And IMHO it's urgent. 
The Blender people are in development of NDOF input support, the 
users are buying 3Dconnexion devices in large stock (you can even get 
discount over some channels), and the longer it takes to implement a 
sane solution (i.e. some way to treat awkwark USBHID devices, I bet 
the SpaceNavigator will not remain the only one, not following the 
rules), the more hackish the client side solutions will become.

Greetings

-- 
Wolfgang Draxinger
lead programmer - DARKSTARgames
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.x.org/archives/xorg/attachments/20080311/192f7d81/attachment.pgp>