Fw: HID hotplug

[David Brownell <david-b@pacbell.net>]

There's some discussion of input device hotplugging over on
the linux-usb-devel list, for those interested.

----- Original Message ----- 
From: "Vojtech Pavlik" <vojtech@suse.cz>
To: <stewart@wetlogic.net>
Cc: "David Brownell" <david-b@pacbell.net>; <linux-usb-devel@lists.sourceforge.net>
Sent: Wednesday, February 28, 2001 12:33 AM
Subject: Re: HID hotplug


> On Wed, Feb 28, 2001 at 12:30:50AM -0800, Paul Stewart wrote:
> 
> > >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.
> > 
> > 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.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel