On Thu, 17 May 2007, Tomas Carnecky wrote: > Additional info: HID device has two collections (whatever those are, I > have _no_ idea):
If you are interested what usages and collections are (and if you are going to write the support for this device, you probably are :) ), please see http://www.usb.org/developers/hidpage - namely http://www.usb.org/developers/devclass_docs/HID1_11.pdf and possibly also http://www.usb.org/developers/devclass_docs/Hut1_12.pdf > The culprit is the IS_INPUT_APPLICATION() macro, which only accepts > certain 'usage' types. Should it also accept this particular one, too, > or even the whole 'Telephony' group? Or maybe add a (configurable) > 'quirk' to enable the GameVoice device? We don't want neither the 'Telephony' nor 'LEDs' usages to be claimed by the hid-input system, that seems to make a little sense. So either the device is bogus and has broken report descriptor (which we could fix in runtime), or it really can't be handled by hid-input (I have no idea about the purpose and internal working of the device in question, sorry). Either we can fix the hiddev_connect() so that the device would be claimed by hiddev (*) and you can write the driver for this device easily in userland, or you could try to write generic in-kernel hid-telephony.c handler of all telephony devices (but I doubt this is doable in a reasonable way). (*) I currently have no idea why this device is not claimed by hiddev though - it seems to have all collections of type HID_COLLECTION_APPLICATION which obviously are not IS_INPUT_APPLICATION() ... could you please put debugging output into hiddev_connect() to examine why your device is not being claimed by hiddev? Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
