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

Wolfgang Draxinger wdraxinger at
Tue Mar 11 09:31:05 PDT 2008

On Tue Mar 11 2008 Greg KH wrote:

> I agree, what's one more :)

My concern is not the "bloat" it adds to the kernel. My concern is, 
that for every new device that need quirks you then need an update of 
the usbhid kernel module, just to get the additional table entries.

--- Here's the scenario if the quirks tables were hardcoded
--- into the kernel:

The user buys this brand new USB-HID device, which quicks modi have 
not yet found their way into the kernel. He plugs it into his 
computer, the device gets properly registered with the input system 
and actually can be accessed, but for some reason it doesn't work the 
way he expects. He does a search on "device blabla Linux Input 
HOWTO", but the results just point to LKML or similair. Now he has to 
wait for the maintainer to patch the quirks table of usbhid (1 hour 
task, if a kernel hacker gets the device to play around with, to test 
the quirks), but then we've to wait for the official kernel release 
and then the distributions to deliver it.

In the meantime the user is stuck with a device he can't use, because 
it misbehaves, and eventually blames Linux for this.

--- Now consider usermode quirks tables:

User plugs in device, device doesn't behave correctly. User does a 
search "device blabla Linux Input HOWTO" and in response he gets a 
page, that tells him, that the device needs some quirks enabled. To 
do so download "XX-blabla.rules" or "blabla.fdi" and place it 
in /etc/udev/rules.d or /usr/share/hal/fdi, calls udevtrigger et 
voila: Device works => User is happy.


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

More information about the xorg mailing list