On Tue, 5 Mar 2002 08:47, Greg KH wrote: > On Tue, Mar 05, 2002 at 07:39:57AM +1100, Brad Hards wrote: > > On Tue, 5 Mar 2002 06:37, Greg KH wrote: > > > On Sun, Mar 03, 2002 at 02:33:20AM -0500, Matt Matthews wrote: > > > > usbmouse 1824 0 (unused) > > > > usbkbd 2944 0 (unused) > > > > > > Can you just delete this modules to prevent them from getting loaded? > > > You should not need them at all, and if both are loaded (along with the > > > input drivers, not nice things have been known to happen.) > > > > I think maybe we should look at the Boot Protocol drivers again. > > > > 1. We seem to be confusing users, and we likely will get bit-rot on the > > code 2. We now have dependency on the input drivers (ie. the comments > > above probably aren't exactly true :). usbkbd no longer calls > > handle_scancode directly - it gets passed through the input.o and > > keybdev.o code. 3. The code size difference is there, but it isn't that > > great. > > > > I'd like to suggest ripping out the boot protocol drivers, at least in > > 2.5. > > No, they are still needed for some systems. Think boot disks and other > space constrained places. Is this a real requirement. Space isn't that constrained (bootable business cards are taking over from floppies), and a quick check: [bradh@localhost usb]$ ls -l usbkbd.o usbmouse.o hid.o -rw-rw-r-- 1 bradh bradh 18258 Mar 5 09:27 hid.o -rw-rw-r-- 1 bradh bradh 5928 Mar 5 09:27 usbkbd.o -rw-rw-r-- 1 bradh bradh 4464 Mar 5 09:27 usbmouse.o 8K isn't much for 99% of applications
> > As a middle ground, we could just remove the config options, and leave > > the code, along with a comment in Documentation. I'd like to do this for > > 2.4. > > No. We currently have drivers in the tree that do different things, yet > bind to the same type of devices. Here's two pairs for example: > bluetooth.c and hci_usb.c > ir-usb.c and irda-usb.c But usbkdb/usbmouse and hid don't do different things, so the analogy doesn't hold. The examples you are presenting are presenting different interfaces. hid is a superset of boot protocol, not a different interface. A better analogy would be the uhci drivers. Do you want both of those? > Should one of these pairs go away too? I don't think so. Each of them > fill a need for someone, just like the Boot protocol drivers do. It's > up to the user to be "smart" enough to not enable the incorrect one. > And it's up to us to document this to allow the user to make the correct > "smart" decision :) Oh, how I have tried... :) The depth of understanding required to really figure out what boot protocol means is beyond most users. They aren't reading docs, and they are stuffing it up. By contrast, the people trying to build systems that minimise RAM usage and disk space will put the effort in. > I also remember some older USB keyboards that do not work with the full > HID driver, but works fine with the boot protocol drivers. I need to > try to dig that device up. That is a different case. Now there is a downside to HID. There are three options: 1. Not support this hardware (relying on BIOS support) 2. Keep the boot protocol driver, but modify it to match on vendor and product IDs, since these aren't really HID devices (so blacklist them like the wacom case) 3. Modify HID to deal with these devices (if possible). Brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
