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:

> Umm, why would you have _two_ drivers?

It would still be one: evdev. There'd be just a entry in sysfs (didn't 
thought of that in the first place, doesn't need extra IOCTLs, like I 
suggested first), which can be perfectly set through UDev.

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

I can understand it for single chipsets, or other specific HW. But 
USBHID is generic to the bone, and it's device neutral. Having the 
quirks table in the kernel would mean, that for every awkward device 
you'd have to get the latest kernel, or if it's not in there yet 
patch it. It might be a hacker friendly solution, but I'm thinking 
here about the average user (admin) here, who just want's to install 
his Ubuntu/Fedora/etc. and doesn't want to wait for 2 months until 
the distributions finally marked an updated kernel as stable.

With a table in userspace (it could be just a large UDev rules file, 
most systems have UDev now anyway) and a interface to the quirks bits 
through sysfs this could be done without introducing new tools. And 
such a table can be updated online without need to rebooting into an 
updated kernel.

And it would also keep the memory footprint small --- okay, say one 
page for a quirks table doesn't hurt, but still: why do it if it can 
be done from userspace in more flexible and friendly way?

Greetings

-- 
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/661e20e8/attachment.pgp>