Hi Jiri, > > For me the task of converting HID reports into input events shouldn't be > > actually the job of the HID core layer. My understanding is that the HID > > core should support multiple transport layers. This is currently > > achieved through the hid_device abstraction and used by the USB and by > > the Bluetooth subsystem. This is the lower interface to HID. On the > > upper interface I like to see a driver like interface. So we can > > register specific drivers that can handle specific use cases or vendor > > specific reports. > > This I completely agree with, and have this on my TODO for quite a long > time. If Li Yu would like to spend some time on it, it certainly would > help. The current "simple HID interrface" is a suitable workaround for > various buggy/broken/nonstandard hardware which is currently not handled > by the HID kernel code properly, but it's definitely not a long-term > solution that should go to mainline.
my point is basically that we shouldn't waste any effort on a simple driver while we actually need a generic driver interface. This generic interface might be look simple and stupid in the beginning, but it can easily grow over time. With this interface of course we need the concept of a HID bus. > > For standard keyboard and mouse reports we however should have a > > standard driver that can handle most of them. > > Unfortunately there is a non-trivial bunch of hardware that pretends to be > standard keyboard/mouse, but behaves badly. Last week I had to do > workaround for Logitech S510, which seems to generate usages far above the > logical maximum specified in report descriptor, to give one example. > > So we will probably end up with many small driver for exotic pieces of > hardware being registered to the hid bus. But this is definitely much > better than the current mess of hid quirks. Maybe the report descriptor is broken. I have some Bluetooth HID where they actually byte-swapped values and it totally confused the report descriptor parser. For some devices it might be better to actually patch the report descriptor instead of adding quirks to the HID core. Regards Marcel - 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/
