Hi Marcel and Jiri > Hi Jiri, > >>>> What if we were to change the definition of a HID device on the >>>> modalias level? >>>> >>>> In practise, a HID device can be either an usb device, a hid device, >>> >>> Just to be sure: do you mean "bluetooth device"? or is there such a >>> thing as a hid device per se? I'm asking because I've always been >>> surprised at seeing usbhid/ in hid/, which kind of breaks the potential >>> symmetry between USB and Bluetooth wrt hid. >> >> Please don't get confused by the directory layout ... this has mostly >> non-technical reasons -- Marcel wanted to keep bluetooth/hidp under his >> wings, and I didn't have reasons to object strongly. >> >> I am adding Marcel and Gustavo to CC just in case they have changed their >> mind, but it's definitely a side-topic in this discussion. > > I have not changed my mind. HIDP is Bluetooth specific and should stay > there. Especially since we are currently discussing changes to make > things also work over Bluetooth Low Energy (LE), but that is a complete > different topic and it just started. Just in case it makes a difference, I knew nothing about HIDP when I wrote the message above. My point was rather that hid looks like a bus to which several transport layers can connect (USB, Bluetooth, ZigBee, etc), and that having USB-specific code in hid/ (as opposed to having it in usb/) seems biased towards USB. I was (and am still) wondering how much it limits future uses of the hid core by making it USB-dependent. In other words: is the hid core generic enough or are there steps to take to make it more generic wrt transport layers? If we are talking about restructuring parts of it, this seems like the right time to ask :-) Cheers, St. -- 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
