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 Daniel Stone:

> Hi,
> The problem is that we don't want to encourage people to fix up
> this kind of insanity in the evdev driver.

And GKH tries to get rid of all quirks in the kernel, that's gonna be 
a circular dependency :-) I can already see his argumentation: "Do it 
in the user space. A program that uses event interface might so it 
just like this:

if( EV_ABS == ev.type ||
    quirks_rel_absolute && EV_REL == ev.type ) {
        ProcessAbsEvent(device, ev);
} else if ( EV_REL == ev.type ) {
/* ... */
}

> If you provide the 
> option, then people will come up with the most daft uses for it.

So be it. I don't really see a problem there.

> You can use TimerSet/TimerCancel to fire arbitrary timers.

:-) somehow this has slipped me grepping for timer 
in /usr/include/xorg

ATM the headers are my only API documentation on X.Org server 
development, as I have found no in depth reference docs yet. At least 
the function names are obvious.

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

I see.

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

Well, put the functionality into the kernel: Yes
Put the quirks table into the kernel: No!

There's no need for a table in the kernel anyway, such things can be 
done with UDev in a perfectly safe way from userspace. The evdev 
would just need an aditional IOCTL, for setting the quirks, 
eventually with an additional IOCTL to freeze quirks settings for a 
device until it's unplugged/driver unloaded.

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

Makes sense.

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

http://www.3dconnexion.com/buy/locate_reseller.php

To know if there's a discount currently running somewhere, ask the 
little box in Google, or one of the resellers. OTOH this device is 
also affordable without a discount, costs less than a good Keyboard 
(good like in IBM Model M).

-- 
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/1dd04484/attachment.pgp>