Hi Stéphane, > > 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. Oops, yes, I meant bluetooth devices. > > a single interface on a usb bus, a special class determined by examining > > the reports, etc. Yet, the hid modalias contains only bus type, vendor > > and product id. This is true for the generic usb and bluetooth drivers > > (and some very special drivers), but not really for the other devices. > > If we were to extend the modalias description, we could cater for a > > whole tree of hid devices. For instance, the usb id 1234 could be > > handled by the generic usb bus driver. The multitouch sub-device > > 1234:MT could be handled by hid-multitouch. The mouse device > > 1234:Mouse could be handled by some other driver, etc. All the driver > > handling could be automated in userland using the same udev mechanism > > we have today, if only the hid uevents were modified to incorporate > > the needed extra information. > > No comments on this, I need to read up on modaliases before being > able to comment at all. I have a vague feeling that we are going to > end up debating where it is decided to assign a device to a driver > (today it's done in the kernel, you seem to suggest userland), but I > know too little about modaliases to be sure. The device-driver matching is done in the kernel, but driver (aka module) loading is done from userland. The crux is to be able to tell userland what driver to load for a certain device. In this case, it means giving more information to userland via the device/modalias construct. Or at least, that is the question. :-) Thanks, Henrik -- 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
