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

[Daniel Stone]

[Greg, xorg@ is subscribers-only, so you'll get a bounce; sorry in
 advance for the noise.]

On Tue, Mar 11, 2008 at 11:13:15AM +0100, Wolfgang Draxinger wrote:
> Am Dienstag, 11. März 2008 schrieb Daniel Stone:
> > 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 ) {
> /* ... */
> }

Greg, true?  (Background: Some devices send REL events when they really
mean to send ABS.  Wolfgang suggested an option in xf86-input-evdev,
whereas I suggested that the kernel should just have a quirk table based
on vendor/device ID to deal with this itself and send correct events to
_all_ of userspace, not just Xorg.)

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

I didn't, but now I've seen the full gamut of awful 'solutions' people
are prepared to put up with.

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

Yeah, we don't really have anything better, sorry.

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

Umm, why would you have _two_ drivers? The point of evdev is to provide
an abstraction layer, so if you need to have layering violations to
provide userspace a way to say 'hey, I think your driver needs a fix,
please do _this_', then you have two drivers (usbhid in the kernel and
HAL or whatever in userspace), not one.

Quirk tables are all through the USB code[0], IDE, etc, already, so this
would be the accepted practice.

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

Okay, I'll get on it.  Hopefully I can pick up a Wacom for a decent
price as well, as I'm trying to get back on the input bandwagon,
although I suspect my next few months will just involve XKB.

Cheers,
Daniel

[0]: On the hal list today or last night, I saw one for a GSM modem
     which provided a CD device with Windows device drivers; the kernel
     has a quirk to disable this and only provide serial.
-------------- 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/887fe430/attachment.pgp>