[Adding linux-input and specifucally Jiri Kosina] On Tue, Mar 11, 2008 at 01:52:47PM +0100, Nicolas Mailhot wrote: > > Le Mar 11 mars 2008 13:28, Wolfgang Draxinger a ??crit : > > Am Dienstag, 11. M??rz 2008 schrieb Daniel Stone: > > > >> 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. > > I'd be very careful not to assume what can or can not be done at > kernel level, and what should and should not belong in the kernel. > > The kernel HID people are the ones who see all the hardware diversity > and what people need. They're the ones you should consult first before > adding a quirks table somewhere else. Because if they have to > implement a quirks table in the kernel anyway (for some need you've > not envisionned today) having two layers of quirks that fight each > other for device control is going to make life miserable for everyone. > I think that if EV_ABS for a device is the one that really makes sense and the device sends EV_REL in error we should just adjust the type of events right in USBHID driver so incorrect events don't propagate any further. If hovewer preference of EV_ABS vs EV_REL is just something xf86-evdev wants just because of its internal architecture then the quirk belongs to xf86-evdev itself. Jiri, apparently some 3Dconnexion devices send EV_REL which makes xf86-evdev not too happy. What do you think? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
