input-evdev patch adding option to override XDevice type Atom, option to force EV_REL events being treated as absolute values.
wdraxinger at darkstargames.de
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...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the xorg