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

[Daniel Stone]

[Dmitry, Ccing you even though xorg@ is subscribers-only posting.
Sorry.]

On Tue, Mar 11, 2008 at 02:41:42AM +0100, Wolfgang Draxinger wrote:
> 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.

Hi,
The problem is that we don't want to encourage people to fix up this
kind of insanity in the evdev driver.  If you provide the option, then
people will come up with the most daft uses for it.  Better to just take
a little bit of pain waiting for a kernel update, in order to safeguard
our future.

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

You can use TimerSet/TimerCancel to fire arbitrary timers.

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

Actually, yes, we need absolute events from relative devices anyway, to
get rid of the last of XFree86-DGA.

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

Well, xEvents are only 32 bytes, and the motion ones are jam-packed
full.

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

Right, but the device database should be in the kernel, as a quirk
table.  The design of evdev (as a general sense, not xf86-input-evdev
specifically) was such that the kernel would normalise events and pass
them through to dumb, trusting, clients, precisely to avoid the PS/2
fiasco, where interpreting a 'standard' protocol was next to impossible.

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

Have you got a link? I'd be interested in picking one up ...

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080311/08e8487e/attachment.pgp>