From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Wed, 28 Feb 2001 16:27:07 +0000 Subject: Fw: HID hotplug Message-Id: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org There's some discussion of input device hotplugging over on the linux-usb-devel list, for those interested. ----- Original Message ----- From: "Vojtech Pavlik" To: Cc: "David Brownell" ; 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