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

[Greg KH]

On Tue, Mar 11, 2008 at 05:31:05PM +0100, Wolfgang Draxinger wrote:
> 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.

Nice walk through.  Now consider how it would be better:
	The manufacturer tests their device on Linux before it ships and
	realizes that it doesn't properly work.  They contact the kernel
	developers who make a patch and get it into the kernel before
	the device is available to the public.  When the user buys the
	device and plugs it in, everything "just works".

Now before you seize up laughing, realize that this already happens
today for a wide variety of manufacturers and devices, and more and more
are working with the kernel developers to make this happen.  So don't
write it off as a fantasy.

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

What's wrong with:
	user uses Yast2/whatever config tool that writes a new entry to
	the kernel's quirk table at boot, enabling the device to work
	properly.

This already happens today with new device ids for PCI and USB.

So, how specifically are you going to write a udev rule to change this?
I want to see a patch :)

thanks,

greg k-h