On Tue, 5 Mar 2002 09:57, Greg KH wrote: > 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 :) They already deal with this problem using modules > And remember, the bootable image on a CDROM still has the "old" 1.4Mb > floppy size requirements. But the driver doesn't have to be built in.
> > > > 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. Err, not so. Boot Protocol is meant to be used where you don't have a HID parser. We do. The whole usbkbd and usbmouse stuff is legacy we don't need. > > 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 :) They don't fix it. They come asking for help. There is a better way :) > Sounds like a good FAQ question for the web page. Maybe, but removing it is still better. > > 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 :) So dump it completely, and stop stuffing around with it. > > > 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). Which could well use a decent HID parser. > > 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. Err, no. The device not working with full HID is in violation of the spec, us taking special action to deal with it isn't. > > 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. I like this option as well. Because then we can dump usbkbd and usbmouse :-) Brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
