HID hotplug

Quoted 33 lines

Quoted 2 lines

But how about "joydev", "keybdev" ... ?

I'm glad you asked. I've actually never gotten as far as to use these devices (my experience is of the "non-input" variety) except to test continued functionality using the "evdev" driver. Your concern is quite valid, and I overlooked this due to inexperience with the input subsystem. On further inspection this is, however, a part of the input subsystem and not the hid subsystem. This distinction is important, since input.o, joydev.o and friends do not depend on hid, and are meant to abstract away the method with which the device is attached.

The decision of which higher-level input driver should be loaded should, as a result not depend on any of the USB or HID attributes of the device. The telling code in joydev.c that shows how the decision gets made as to whether this device is appropriate for binding is in joydev_connect():

        if (!(test_bit(EV_KEY, dev->evbit) && test_bit(EV_ABS, dev->evbit) &&
             (test_bit(ABS_X, dev->absbit) || test_bit(ABS_Y, dev->absbit)) &&
             (test_bit(BTN_TRIGGER, dev->keybit) || test_bit(BTN_A, dev->
keybit)
                || test_bit(BTN_1, dev->keybit)))) return NULL; 

This is the segment that needs to be encoded in a MODULE_DEVICE_TABLE manner, but for a "modules.inputmap" to be certain, and not a "modules.hidmap". The "/sbin/hotplug" call from the kernel would need to encode all the dev->*bit values for comparison. Some care needs to be taken in deciding whether to put all the expressiveness of the above statement in the table itself, or whether this needs logic in the hotplug script itself. Since the information above is fairly static and abstracted away from the specifics of how the device is attached, it's fair to assume that this won't be as subject to change as vendor codes.

Quoted 2 lines

Although Vojtech has been relatively silent so far, I think this one really needs his input before proceeding.

Yes, you're absolutely right. The above expressions should be possible to split into a couple of entries containing required bits to be set for the device to be accepted. Now that I'm finishing the VIA drivers I'll be able to look at this soon. Patches are welcome, though.

Oh, and vendor codes are also available in the input_dev struct, I'd like them to be possible to specify as well for matching the device.

Signature · 2 lines

Vojtech Pavlik
SuSE Labs