On Wed, 2010-02-10 at 13:52 +0100, Jiri Kosina wrote: > On Mon, 8 Feb 2010, Bastien Nocera wrote: > > > > > > > +With 0x05ac being the vendor ID (Apple, you shouldn't need to change this) > > > > > > +With 0x8242 being the product ID (check the output of lsusb for your hardware) > > > > > > +And 0x08 being "HID_CONNECT_HIDDEV" > > > > > > > > > > I am afraid this is not true, 0x08 is HID_QUIRK_NOGET. > > > > > > > > > > We currently don't have dynamic quirk for forcing HIDDEV creation from the > > > > > module parameter. > > > > > > > > Right. Any chance to change that? > > > > > > This particular one might actually make enough sense to be added (although > > > I am really trying to avoid quirk additions completely), for backwards > > > compatibility reasons. > > > > Should I remove the comments there altogether then? That kind of defeats > > my "but you can use lirc with some tweaks" argument, even though I still > > think that those people needing more keys would be in the minority... > > I rather though that we could/should (re-)introduce the HID_QUIRK_HIDDEV > quirks so that it could still be applied manually. The interaction between the HID and the input layer isn't really my forte (well, the kernel's not my forte :). Wouldn't we have some trouble getting the HID layer provide a hiddev device for the receiver, whilst being serviced by an input driver? I wouldn't mind trying to port the driver to be a full HID driver, and enable hiddev all the time on it. We just wouldn't do anything in the input part if the hiddev device was claimed, and parse the raw_report from the device otherwise. Opinions? If it's a good idea, I'd be interested in some examples in devices that do their own raw_report event parsing, instead of letting the hid layer handle it. -- 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
