Happy Hacking Keyboard Lite Mk 2 USB Problems with 2.4.18.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines
My theory is that usbkbd.o doesn't cope with ErrorRollover which is being generated, unlike hid.o which didn't used to but does now.
I have an idea: remove usbkbd or make it extremely hard for newbies to build (e.g. drop CONFIG_USB_KBD from config.in, so it would need to be added manually if you want usbkbd).
At the very minimum I would like to see all distros, and especially SuSE (because of Vojtech) to stop shipping usbkbd.o.
-- Pete
Hi,
Quoted 2 lines · Pete Zaitcev
At the very minimum I would like to see all distros, and especially SuSE (because of Vojtech) to stop shipping usbkbd.o.
Mandelbrot:~ # zgrep CONFIG_USB_KBD /proc/config.gz # CONFIG_USB_KBD is not set
Quoted 1 line
-- Pete
-o)
Hubert Mantel Goodbye, dots... /\\
_\_vHi Pete,
Quoted 6 lines
Quoted 2 lines
My theory is that usbkbd.o doesn't cope with ErrorRollover which is being generated, unlike hid.o which didn't used to but does now.
I have an idea: remove usbkbd or make it extremely hard for newbies to build (e.g. drop
CONFIG_USB_KBDfrom config.in, so it would need to be added manually if you want usbkbd).
That doesn't sound too great.
Quoted 2 lines
At the very minimum I would like to see all distros, and especially SuSE (because of Vojtech) to stop shipping usbkbd.o.
What I'd like to see, if both hid.o and usbkbd.o can handle a keyboard, is that hid.o gets the job. Then usbkbd.o can stay in config.in and be built just in case it's needed.
Quoted 5 lines
Quoted 2 lines
I'll try and use hid.o instead, usbkbd.o was just picked by this Red Hat 7.2 system on adding the keyboard.
Do up2date and be happy: usbkbd.o was removed from Red Hat kernels somewhere in erratas.
Ah, OK, thanks. Unfortunately, I've already moved onto 2.4.18 built from source due to some of my other needs.
Cheers,
Ralph.
Quoted 3 lines · Ralph Corderoy
What I'd like to see, if both hid.o and usbkbd.o can handle a keyboard, is that hid.o gets the job. Then usbkbd.o can stay in config.in and be built just in case it's needed.
usbkbd.o is never needed when hid.o is present unless I have misunderstood something.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
I'll try and use hid.o instead, usbkbd.o was just picked by this Red Hat 7.2 system on adding the keyboard.
Do up2date and be happy: usbkbd.o was removed from Red Hat kernels somewhere in erratas.
Ah, OK, thanks. Unfortunately, I've already moved onto 2.4.18 built from source due to some of my other needs.
In that case just reconfigure your kernel not to include usbkbd and use hid instead, recompile, and be happy.
Best regards,
Anton
Signature · 5 lines
"I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov <aia21 at cantab.net> (replace at with @) Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Hi Anton,
Quoted 6 lines
Quoted 3 lines
What I'd like to see, if both hid.o and usbkbd.o can handle a keyboard, is that hid.o gets the job. Then usbkbd.o can stay in config.in and be built just in case it's needed.
usbkbd.o is never needed when hid.o is present unless I have misunderstood something.
Ah, I thought that in the same way the BIOS might not support the HID interface and so can use the simpler Boot interface, a keyboard might not implement the HID interface and just implement the simpler Boot one. Apologies if this isn't the case. I agree that hid.o should be able to cope with everything then.
Quoted 5 lines
Quoted 2 lines
Ah, OK, thanks. Unfortunately, I've already moved onto 2.4.18 built from source due to some of my other needs.
In that case just reconfigure your kernel not to include usbkbd and use hid instead, recompile, and be happy.
Yes, that's what I've done, and I'm happy, but still wish to persue the problem in order that usbkbd.o gets fixed. Otherwise, someone else will spend their weekend learning about usbkbd.c, HID, Boot, etc. :-)
Cheers,
Ralph.
Quoted 7 lines · Ralph Corderoy
Hi Anton,
Quoted 4 lines
Quoted 3 lines
What I'd like to see, if both hid.o and usbkbd.o can handle a keyboard, is that hid.o gets the job. Then usbkbd.o can stay in config.in and be built just in case it's needed.
Quoted 8 lines
Quoted 2 lines
usbkbd.o is never needed when hid.o is present unless I have misunderstood something.
Ah, I thought that in the same way the BIOS might not support the HID interface and so can use the simpler Boot interface, a keyboard might not implement the HID interface and just implement the simpler Boot one. Apologies if this isn't the case. I agree that hid.o should be able to cope with everything then.
No, this is not the case. Even if the device implements only one mode and that mode is HIDBP compatible, it's still also HID compatible, because HIDBP is a subset of HID.
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
Ah, OK, thanks. Unfortunately, I've already moved onto 2.4.18 built from source due to some of my other needs.
In that case just reconfigure your kernel not to include usbkbd and use hid instead, recompile, and be happy.
Yes, that's what I've done, and I'm happy, but still wish to persue the problem in order that usbkbd.o gets fixed. Otherwise, someone else will spend their weekend learning about
usbkbd.c, HID, Boot, etc. :-)
usbkbd.c will get fixed. No worries.
Signature · 2 lines
Vojtech Pavlik SuSE Labs
Quoted 10 lines
Date: Mon, 01 Jul 2002 17:47:23 +0100
From: Ralph Corderoy <[email protected]>Quoted 6 lines
Quoted 2 lines
My theory is that usbkbd.o doesn't cope with ErrorRollover which is being generated, unlike hid.o which didn't used to but does now.
I have an idea: remove usbkbd or make it extremely hard for newbies to build (e.g. drop
CONFIG_USB_KBDfrom config.in, so it would need to be added manually if you want usbkbd).
Quoted 8 lines
That doesn't sound too great.
Quoted 2 lines
At the very minimum I would like to see all distros, and especially SuSE (because of Vojtech) to stop shipping usbkbd.o.
What I'd like to see, if both hid.o and usbkbd.o can handle a keyboard, is that hid.o gets the job. Then usbkbd.o can stay in config.in and be built just in case it's needed.
This is exactly why today's situation is broken. Users (and even developers) sometimes find that hid does not work. So, they compile usbkbd and move along. This means that hid never can reach into certain corner cases, such as the infamous HP keyboard p/n 5184-4708.
-- Pete
Quoted 10 lines · Ralph Corderoy
Hi Pete,
Quoted 6 lines
Quoted 2 lines
My theory is that usbkbd.o doesn't cope with ErrorRollover which is being generated, unlike hid.o which didn't used to but does now.
I have an idea: remove usbkbd or make it extremely hard for newbies to build (e.g. drop
CONFIG_USB_KBDfrom config.in, so it would need to be added manually if you want usbkbd).That doesn't sound too great.
Actually, it would probably avoid a lot of unhappy users, and I am a strong advocate of total removal of the code, config option, everything. The only downside is slightly larger code size for hid.o vs usbkbd.o.
Unfortunately, removal has been vetoed by the USB Maintainer based on the code size issue.
Hmm, maybe we can add a particularly inefficient ErrorRollover handling case to usbkbd :-)
Brad
Signature · 1 line
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
Quoted 9 lines
From: Brad Hards <[email protected]>
Date: Tue, 2 Jul 2002 14:16:42 +1000Quoted 3 lines
Quoted 3 lines
I have an idea: remove usbkbd or make it extremely hard for newbies to build (e.g. drop
CONFIG_USB_KBDfrom config.in, so it would need to be added manually if you want usbkbd).Unfortunately, removal has been vetoed by the USB Maintainer based on the code size issue.
Was it during the Randy's, JE's or Greg's reign? Their ideas about a direction of development were sometimes different.
-- Pete
Quoted 7 lines · Pete Zaitcev
Quoted 7 lines
From: Brad Hards <[email protected]>
Date: Tue, 2 Jul 2002 14:16:42 +1000Quoted 3 lines
Quoted 3 lines
I have an idea: remove usbkbd or make it extremely hard for newbies to build (e.g. drop
CONFIG_USB_KBDfrom config.in, so it would need to be added manually if you want usbkbd).
Quoted 5 lines
Quoted 2 lines
Unfortunately, removal has been vetoed by the USB Maintainer based on the code size issue.
Was it during the Randy's, JE's or Greg's reign? Their ideas about a direction of development were sometimes different.
Here is the latest (from Greg):
http://marc.theaimsgroup.com/?l=linux-usb-users&m=101531496915989&w=2
I may have proposed removal before - it is a bit of a pet topic. So far all I have done is got some strongly worded (if unread) Config.help entries in.
Brad
Signature · 1 line
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.