On Wed, 2010-02-10 at 13:52 +0100, Jiri Kosina wrote:

On Mon, 8 Feb 2010, Bastien Nocera wrote:

quoted

quoted

quoted

quoted

quoted

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