On Tue, Mar 05, 2002 at 09:52:47AM +1100, Brad Hards wrote: > 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
Tell that to the people who have to make distro boot disk images :) And remember, the bootable image on a CDROM still has the "old" 1.4Mb floppy size requirements. > > > 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. Exactly. But for some people, the usbkbd driver is very usable, and is all they really need. The whole HID parser is overkill. This is why the boot protocol was created in the first place. > A better analogy would be the uhci drivers. Do you want both of those? Ah, don't make me answer that one :) > > 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. Then they fix it. Remember, we aren't trying to make kernel configuration a task for Aunt Tillie here :) Sounds like a good FAQ question for the web page. > By contrast, the people trying to build systems that minimise RAM usage and > disk space will put the effort in. And we will continue to give them that option. By "orphaning" the driver by removing the ability to easily build it, we subject the thing to potential bit-rot, and the accidental reintroduction of the option due to the main developers being forced to always enable it anyway for their testing (like me :) > > 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) Nope, can't do that. What if we _are_ the BIOS (think Linux BIOS). > 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) Nope, that breaks the USB spec. > 3. Modify HID to deal with these devices (if possible). Much better. I'll dig for my old device that only worked with one of the drivers later tonight and post if there is still a problem. thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
