USB keyboard problem
plasma
I had a usb->ps/2 adaptor, which could connects to a keyboard and a
mouse. Connecting to my IBM ThinkPad X23, FreeBSD could detects two
usb devices:
ukbd0: GM-TEK USB Composite Device, rev 1.01/0.01, addr 2, iclass 3/1
kbd1 at ukbd0
ums0: GM-TEK USB Composite Device, rev 1.01/0.01, addr 2, iclass 3/1
ums0: 3 buttons and Z dir.
The mouse is good, and it works perfectly. But the keyboard has a
problem. If I type a little fast, some characters will repeat. Say I
just keep repeating 'd' and 'f', I might get:
dfdfddfddfddfddf
This is annoying! The ukbd is just nearly unusable. I've tested on
4.8-p8, 4.9-PRERELEASE, and 4.9-PRERELEASE with
http://www.josef-k.net/misc/RELENG_4-USB-20030828.patch.gz patch.
Nothing improves.
The same adaptor and keyboard was tested on Windows and Linux. They
worked just perfectly. The characters showed up smoothly no matter
how fast I typed, and didn't repeat itself.
I did some google and found
http://lists.freebsd.org/pipermail/freebsd-questions/2003-August/015018.html
had the same problem like I had. But there seems no follow ups.
Could somebody help?
plasma
==========================================================
學電腦還有補助 ,不怕別人搶飯碗!!
http://edm-prg.epaper.com.tw/click.php?ad_code=24259
==========================================================
PChome線上購物週年慶：抽汽車、DV天天送
http://shopping.pchome.com.tw/
==========================================================
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
plasma
> On Thu, Sep 25, 2003 at 05:35:48PM +0800, plasma wrote:
> > The same adaptor and keyboard was tested on Windows and Linux. They
> > worked just perfectly. The characters showed up smoothly no matter
> > how fast I typed, and didn't repeat itself.
>
> or was it on completely different machine? If the later, then maybe the
> adapter does not like that Thinkpad?
>
> Hope this helps.
>
No, it was tested on different machines, but I don't think it matters.
I believe the ukbd.c has some problem that it cannot handle by itself.
I'll discover in another post what I found these two days.
plasma
==========================================================
收到帳單後最擔心的事
http://edm-prg.epaper.com.tw/click.php?ad_code=25227
plasma
I tried to find what the problem is. I add the following patch to
ukbd.c:
[[[
--- /usr/src/sys/dev/usb/ukbd.c.orig Mon Mar 31 08:31:35 2003
+++ /usr/src/sys/dev/usb/ukbd.c Sat Sep 27 01:31:54 2003
@@ -693,6 +693,12 @@
int mod, omod;
int key, c;
int i, j;
+#ifdef USB_DEBUG
+ static int dumped_empty_queue = 1;
+#endif
+#if 1
+ int no, nn;
+#endif
#define ADDKEY1(c) \
if (state->ks_inputs < INPUTBUFSIZE) { \
@@ -728,20 +734,121 @@
? KEY_PRESS : KEY_RELEASE));
}
+#ifdef USB_DEBUG
+ if (ud->keycode[0] || !dumped_empty_queue) {
+ DPRINTF(("before old: "));
+ for (i = 0; i < NKEYCODE; i++) {
+ if (state->ks_odata.keycode[i])
+ DPRINTF(("%d ", state->ks_odata.keycode[i]));
+ }
+ DPRINTF(("\n"));
+ DPRINTF(("before new: "));
+ for (i = 0; i < NKEYCODE; i++) {
+ if (ud->keycode[i])
+ DPRINTF(("%d ", ud->keycode[i]));
+ }
+ DPRINTF(("\n"));
+
+ dumped_empty_queue = (ud->keycode[0]) ? 0 : 1;
+ }
+#endif /* USB_DEBUG */
+
+#if 1
+ /* Calculate length of old and new data */
+ for (no = 0; no < NKEYCODE; no++) {
+ if (!state->ks_odata.keycode[no])
+ break;
+ }
+ for (nn = 0; nn < NKEYCODE; nn++) {
+ if (!ud->keycode[nn])
+ break;
+ }
+
+#ifdef USB_DEBUG
+ if (no != 0 || nn != 0) {
+ DPRINTF(("no: %d, nn: %d\n", no, nn));
+ }
+#endif /* USB_DEBUG */
]]]
Add 'options USB_DEBUG' in kernel config, and build kernel. Do
'sysctl -w hw.usb.ukbd.debug=1' as well. Now I can see what's going
on inside.
A very interesting things show up. Below is a segment of generated
log:
Sep 27 01:37:28 plasmanb /kernel: before old: 12
Sep 27 01:37:28 plasmanb /kernel: before new: 22 12
Sep 27 01:37:28 plasmanb /kernel: no: 0, nn: 1
Sep 27 01:37:28 plasmanb /kernel: 0x16 (22) pressed
Sep 27 01:37:28 plasmanb /kernel: 22 12
Sep 27 01:37:28 plasmanb /kernel: before old: 22 12
Sep 27 01:37:28 plasmanb /kernel: before new: 22 12
Sep 27 01:37:28 plasmanb /kernel: no: 1, nn: 1
Sep 27 01:37:28 plasmanb /kernel: before old: 22 12
Sep 27 01:37:28 plasmanb /kernel: before new: 22
Sep 27 01:37:28 plasmanb /kernel: no: 1, nn: 1
Sep 27 01:37:28 plasmanb /kernel: before old: 22
Sep 27 01:37:28 plasmanb /kernel: before new: 22
Sep 27 01:37:28 plasmanb /kernel: no: 1, nn: 1
Sep 27 01:37:28 plasmanb /kernel: before old: 22
Sep 27 01:37:28 plasmanb /kernel: before new: 22
Sep 27 01:37:28 plasmanb /kernel: no: 1, nn: 1
Sep 27 01:37:28 plasmanb /kernel: before old: 22
Sep 27 01:37:28 plasmanb /kernel: before new: 22 44
Sep 27 01:37:28 plasmanb /kernel: no: 1, nn: 2
Sep 27 01:37:28 plasmanb /kernel: 0x2c (44) pressed
Sep 27 01:37:28 plasmanb /kernel: 22 44
Sep 27 01:37:28 plasmanb /kernel: before old: 22 44
Sep 27 01:37:28 plasmanb /kernel: before new: 22 44
Sep 27 01:37:28 plasmanb /kernel: no: 2, nn: 2
Sep 27 01:37:28 plasmanb /kernel: before old: 22 44
Sep 27 01:37:28 plasmanb /kernel: before new: 22 44
Sep 27 01:37:28 plasmanb /kernel: no: 2, nn: 2
Sep 27 01:37:28 plasmanb /kernel: before old: 22 44
Sep 27 01:37:28 plasmanb /kernel: before new: 44
Sep 27 01:37:28 plasmanb /kernel: no: 2, nn: 0
Sep 27 01:37:28 plasmanb /kernel: 0x416 (1046) released
Sep 27 01:37:28 plasmanb /kernel: 0x42c (1068) released
Sep 27 01:37:28 plasmanb /kernel: 44
The problem is here:
Sep 27 01:37:28 plasmanb /kernel: before old: 22 44
Sep 27 01:37:28 plasmanb /kernel: before new: 44
Sep 27 01:37:28 plasmanb /kernel: no: 2, nn: 0
Sep 27 01:37:28 plasmanb /kernel: 0x416 (1046) released
Sep 27 01:37:28 plasmanb /kernel: 0x42c (1068) released
The dumping code
for (i = 0; i < NKEYCODE; i++) {
if (ud->keycode[i])
DPRINTF(("%d ", ud->keycode[i]));
}
shows there's one element in the new key data, but the later counting
loop
for (nn = 0; nn < NKEYCODE; nn++) {
if (!ud->keycode[nn])
break;
}
says there's no element inside the new key data. How could it be
possible? And why?
I believe if this mystery could be solved, then we'll have a happy usb
keyboard driver.