Hi,
Does anyone here have a USB Happy Hacking Keyboard Lite Mk 2 keyboard?
On connecting to my 2.4.18 Linux system I find that it works great,
except that certain triples of keys produce four characters instead of
three when typed in rapid succession. This happens under XFree86 and
also at a tty. For example, typing `swa' rapidly produces `swaw'.
Further investigation revealed that only certain combination of keys
exhibit the problem. More examples are
keys produces
rty rtty
yui yuui
tyu tyuy
swa swaw
jhg jhgh
But other won't show the problem, e.g. `zxc', `asd', and `qwe'.
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.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0104.2/1022.html
Diffing 2.4.18's usbkbd.c against 2.5.7 suggests the problem still
exists in 2.5.7.
I'd like to know that others can re-produce the problem.
Cheers,
Ralph.
On Mon, 1 Jul 2002 21:02, Ralph Corderoy wrote:
> Hi,
>
> Does anyone here have a USB Happy Hacking Keyboard Lite Mk 2 keyboard?
>
> On connecting to my 2.4.18 Linux system I find that it works great,
> except that certain triples of keys produce four characters instead of
> three when typed in rapid succession. This happens under XFree86 and
> also at a tty. For example, typing `swa' rapidly produces `swaw'.
What is the event interface (dev/input/eventX) showing for this type of input?
> Further investigation revealed that only certain combination of keys
> exhibit the problem. More examples are
>
> keys produces
> rty rtty
> yui yuui
> tyu tyuy
> swa swaw
> jhg jhgh
>
> But other won't show the problem, e.g. `zxc', `asd', and `qwe'.
>
> 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.
Err, how do you reconcile that with only seeing it on some keys?
BTW: usbkbd isn't meant for real work. You should use full HID.
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
Hi Brad,
> > For example, typing `swa' rapidly produces `swaw'.
>
> What is the event interface (dev/input/eventX) showing for this type
> of input?
I was previously unaware of /dev/input/* and unfortunately I get ENODEV
for all of the event* files in there.
However, adding printk()s to usbkbd.c:usb_kbd_irq() gives
1 new: 00 00 16 00 00 00 00 00 s
2 old: 00 00 00 00 00 00 00 00
3 leds: 0 newleds: 0 open: 1
4 new: 00 00 1a 16 00 00 00 00 ws
5 old: 00 00 16 00 00 00 00 00 s
6 leds: 0 newleds: 0 open: 1
7 new: 00 00 01 01 01 01 01 01 ErrorRollover
8 old: 00 00 1a 16 00 00 00 00 ws
9 leds: 0 newleds: 0 open: 1
10 new: 00 00 04 1a 00 00 00 00 aw
11 old: 00 00 01 01 01 01 01 01 ErrorRollover
12 leds: 0 newleds: 0 open: 1
13 new: 00 00 04 00 00 00 00 00 a
14 old: 00 00 04 1a 00 00 00 00 aw
15 leds: 0 newleds: 0 open: 1
16 new: 00 00 00 00 00 00 00 00
17 old: 00 00 04 00 00 00 00 00 a
18 leds: 0 newleds: 0 open: 1
usb_kbd_irq() ignores the possibility of ErrorRollover so its
comparision of old and new at #10 generates the extra `w'. (The `s',
etc., at the end of some lines is my interpretation of the data.)
This is the device.
T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0472 ProdID=0065 Rev= 1.00
S: Manufacturer=Chicony
S: Product=PFU-65 USB Keyboard
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=keyboard
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl= 24ms
$ od -t x1 /proc/bus/usb/002/003
0000000 12 01 10 01 00 00 00 08 72 04 65 00 00 01 03 04
0000020 00 01 09 02 22 00 01 01 04 e0 00 09 04 00 00 01
0000040 03 01 01 00 09 21 00 01 00 01 22 41 00 07 05 81
0000060 03 08 00 18
0000064
> > keys produces
> > rty rtty
> > yui yuui
> > tyu tyuy
> > swa swaw
> > jhg jhgh
> >
> > But other won't show the problem, e.g. `zxc', `asd', and `qwe'.
> >
> > 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.
>
> Err, how do you reconcile that with only seeing it on some keys?
The keyboard matrix. It can cope with `qwe' all being pressed at once,
but not `swa'. It realises it can't give a reliable answer and
generates ErrorRollover as the USB spec. suggests.
> BTW: usbkbd isn't meant for real work. You should use full HID.
I'll try and use hid.o instead, usbkbd.o was just picked by this Red Hat
7.2 system on adding the keyboard. However, I'd still be interested in
confirming if it is a problem with usbkbd.c or Happy Hacker's
interpretation of the spec.
Cheers,
Ralph.
> 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
>[...]
> 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.
-- Pete
Hi,
On Mon, Jul 01, Pete Zaitcev wrote:
> 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
> -- Pete
-o)
Hubert Mantel Goodbye, dots... /\\
_\_v
Hi Pete,
> > 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).
That doesn't sound too great.
> 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.
> > 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.
At 12:02 01/07/02, Ralph Corderoy wrote:
>Does anyone here have a USB Happy Hacking Keyboard Lite Mk 2 keyboard?
I have two of the Mk2 and one of the Mk1 keyboards and none of them exhibit
the problems you have (using 3 different systems with kernels both
2.4.18-pre7-ac2+ide+other stuff, 2.4.18-pre3+ide+other stuff and
2.5.24+ntfs-2.0.13). The difference being I am using the full HID drivers
(I tried both) and never the cutdown usbkbd driver. (I have many other usb
devices including my mouse, digital camera, webcam, etc, so can't use usbkbd.)
So as other people have suggested, use the full hid driver and be happy. (-:
Best regards,
Anton
>On connecting to my 2.4.18 Linux system I find that it works great,
>except that certain triples of keys produce four characters instead of
>three when typed in rapid succession. This happens under XFree86 and
>also at a tty. For example, typing `swa' rapidly produces `swaw'.
>
>Further investigation revealed that only certain combination of keys
>exhibit the problem. More examples are
>
> keys produces
> rty rtty
> yui yuui
> tyu tyuy
> swa swaw
> jhg jhgh
>
>But other won't show the problem, e.g. `zxc', `asd', and `qwe'.
>
>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.
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0104.2/1022.html
>
>Diffing 2.4.18's usbkbd.c against 2.5.7 suggests the problem still
>exists in 2.5.7.
>
>I'd like to know that others can re-produce the problem.
>
>Cheers,
>
>
>Ralph.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
"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/
At 17:47 01/07/02, Ralph Corderoy wrote:
>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.
> > > 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
--
"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/
> Date: Mon, 01 Jul 2002 17:47:23 +0100
> From: Ralph Corderoy <[email protected]>
> > > 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).
>
> That doesn't sound too great.
>
> > 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
Hi Anton,
> > 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.
> > 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.
On Tue, 2 Jul 2002 02:47, Ralph Corderoy wrote:
> Hi Pete,
>
> > > 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).
>
> 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
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
> From: Brad Hards <[email protected]>
> Date: Tue, 2 Jul 2002 14:16:42 +1000
> > > 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).
> 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
On Tue, 2 Jul 2002 14:26, Pete Zaitcev wrote:
> > From: Brad Hards <[email protected]>
> > Date: Tue, 2 Jul 2002 14:16:42 +1000
> >
> > > > 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).
> >
> > 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
--
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
On Mon, Jul 01, 2002 at 06:46:58PM +0100, Ralph Corderoy wrote:
>
> Hi Anton,
>
> > > 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.
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.
> > > 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.
--
Vojtech Pavlik
SuSE Labs