Re: Re:Re: Linux 2.6.0-test4

Re: Re:Re: Linux 2.6.0-test4

[Chris Heath]

> Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> 
> Basically, CTRL was stuck. Even when I switched to X11.

Well, this completely baffles me.  I thought X11 maintains its own
keydown array.

Anyway, I've included a patch that should hopefully give us better
debugging information.  When you get an unknown key error, it will also
dump the last 16 bytes that were sent from the keyboard.  Be careful
with this one.  If you post any errors to the list, make sure it doesn't
contain any sensitive passwords. :-)

Chris


--- a/drivers/input/serio/i8042.c	2003-08-09 11:58:10.000000000 -0400
+++ b/drivers/input/serio/i8042.c	2003-08-31 10:16:55.000000000 -0400
@@ -62,6 +62,7 @@
 static unsigned char i8042_last_release;
 static unsigned char i8042_mux_open;
 struct timer_list i8042_timer;
+unsigned char i8042_history[16];
 
 /*
  * Shared IRQ's require a device pointer, but this driver doesn't support
@@ -334,6 +335,14 @@
 static char i8042_mux_short[4][16];
 static char i8042_mux_phys[4][32];
 
+void dump_i8042_history(void) {
+	int i;
+	printk(KERN_WARNING "i8042 history: ");
+	for (i=0; i<sizeof(i8042_history); i++)
+		printk("%02x ", i8042_history[i]);
+	printk("\n");
+}
+
 /*
  * i8042_interrupt() is the most important function in this driver -
  * it handles the interrupts from the i8042, and sends incoming bytes
@@ -405,6 +414,8 @@
 			continue;
 		}
 
+		memmove(i8042_history, &i8042_history[1], sizeof(i8042_history)-1);
+		i8042_history[sizeof(i8042_history)-1] = data;
 		if (data > 0x7f) {
 			unsigned char index = (data & 0x7f) | (i8042_last_e0 << 7);
 			/* work around hardware that doubles key releases */
--- a/drivers/input/keyboard/atkbd.c	2003-06-22 18:45:06.000000000 -0400
+++ b/drivers/input/keyboard/atkbd.c	2003-08-31 10:11:51.000000000 -0400
@@ -131,6 +131,7 @@
  * atkbd_interrupt(). Here takes place processing of data received from
  * the keyboard into events.
  */
+void dump_i8042_history(void);
 
 static irqreturn_t atkbd_interrupt(struct serio *serio, unsigned char data,
 			unsigned int flags, struct pt_regs *regs)
@@ -193,6 +194,7 @@
 		case ATKBD_KEY_UNKNOWN:
 			printk(KERN_WARNING "atkbd.c: Unknown key (set %d, scancode %#x, on %s) %s.\n",
 				atkbd->set, code, serio->phys, atkbd->release ? "released" : "pressed");
+			dump_i8042_history();
 			break;
 		default:
 			input_regs(&atkbd->dev, regs);

Re: Re:Re: Linux 2.6.0-test4

[Ralf Hildebrandt]

* Chris Heath <chris@heathens.co.nz>:
> > Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > 
> > Basically, CTRL was stuck. Even when I switched to X11.
> 
> Well, this completely baffles me.  I thought X11 maintains its own
> keydown array.
> 
> Anyway, I've included a patch that should hopefully give us better
> debugging information.  When you get an unknown key error, it will also
> dump the last 16 bytes that were sent from the keyboard.  Be careful
> with this one.  If you post any errors to the list, make sure it doesn't
> contain any sensitive passwords. :-)

I applied your patch, and alas:

Sep  1 16:12:19 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
Sep  1 16:12:19 hummus2 kernel: i8042 history: ae 9d e0 48 e0 c8 e0 38 56 d6 e0 b8 e0 b8 39 b9

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

[PATCH] keyboard - was: Re: Linux 2.6.0-test4

[Andries Brouwer]

[I changed the subject to be slightly more indicative of contents.]

On Mon, Sep 01, 2003 at 06:01:25PM +0200, Ralf Hildebrandt wrote:
> * Chris Heath <chris@heathens.co.nz>:
> > > Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > > Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > 
> > > Basically, CTRL was stuck. Even when I switched to X11.
> > 
> > Well, this completely baffles me.  I thought X11 maintains its own
> > keydown array.

It can do that only when it gets uncontaminated data.

> I applied your patch, and alas:
> 
> Sep  1 16:12:19 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> Sep  1 16:12:19 hummus2 kernel: i8042 history: ae 9d e0 48 e0 c8 e0 38 56 d6 e0 b8 e0 b8 39 b9

I don't know why you say "alas". I read (two key releases, then)
press UpArrow, release UpArrow, RAlt, some key, release some key, release RAlt,
funny: again release RAlt, press space bar, release space bar.

So, nothing "Unknown" about this 0xb9 key - it is the spacebar release.

But i8042.c will do an unxlate when it thinks the key is down, so it
did not think so. But we saw the key down a moment ago. Apparently
the line

	set_bit(data | (i8042_last_e0 << 7), i8042_unxlate_seen);

did not set i8042_unxlate_seen for data = 0x39. And it is clear why:
The sequence e0 b8 e0 b8 is a repetition, the second e0 sets i8042_last_e0,
but after the second b8 we bail out without clearing i8042_last_e0 again.
*BUG*.

Conclusion: in the skipped double release case we must clear i8042_last_e0.

Andries

Vojtech: Note: 1 line should be added in i8042.c:i8042_interrupt().
[A stopgap - in fact all this i8042_unxlate_seen stuff should be ripped out.]

--- serio/i8042.c~      Sat Aug  9 22:16:42 2003
+++ serio/i8042.c       Tue Sep  2 03:09:12 2003
@@ -410,6 +410,7 @@
                        /* work around hardware that doubles key releases */
                        if (index == i8042_last_release) {
                                dbg("i8042 skipped double release (%d)\n", index);
+                               i8042_last_e0 = 0;
                                continue;
                        }
                        if (index == 0xaa || index == 0xb6)

Re: [PATCH] keyboard - was: Re: Linux 2.6.0-test4

[Ralf Hildebrandt]

* Andries Brouwer <aebr@win.tue.nl>:

> > * Chris Heath <chris@heathens.co.nz>:
> > > > Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > > Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > > > Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > > Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > > > 
> > > > Basically, CTRL was stuck. Even when I switched to X11.
> > > 
> > > Well, this completely baffles me.  I thought X11 maintains its own
> > > keydown array.
> 
> It can do that only when it gets uncontaminated data.
> 
> > I applied your patch, and alas:
> > 
> > Sep  1 16:12:19 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > Sep  1 16:12:19 hummus2 kernel: i8042 history: ae 9d e0 48 e0 c8 e0 38 56 d6 e0 b8 e0 b8 39 b9
> 
> I don't know why you say "alas". I read (two key releases, then)
> press UpArrow, release UpArrow, RAlt, some key, release some key, release RAlt,
> funny: again release RAlt, press space bar, release space bar.

This must a known bug of this particular keyboard.

> So, nothing "Unknown" about this 0xb9 key - it is the spacebar release.
> 
> But i8042.c will do an unxlate when it thinks the key is down, so it
> did not think so. But we saw the key down a moment ago. Apparently
> the line
> 
> 	set_bit(data | (i8042_last_e0 << 7), i8042_unxlate_seen);
> 
> did not set i8042_unxlate_seen for data = 0x39. And it is clear why:
> The sequence e0 b8 e0 b8 is a repetition, the second e0 sets i8042_last_e0,
> but after the second b8 we bail out without clearing i8042_last_e0 again.
> *BUG*.
> 
> Conclusion: in the skipped double release case we must clear i8042_last_e0.
> 
> Andries
> 
> Vojtech: Note: 1 line should be added in i8042.c:i8042_interrupt().
> [A stopgap - in fact all this i8042_unxlate_seen stuff should be ripped out.]
> 
> --- serio/i8042.c~      Sat Aug  9 22:16:42 2003
> +++ serio/i8042.c       Tue Sep  2 03:09:12 2003
> @@ -410,6 +410,7 @@
>                         /* work around hardware that doubles key releases */
>                         if (index == i8042_last_release) {
>                                 dbg("i8042 skipped double release (%d)\n", index);
> +                               i8042_last_e0 = 0;
>                                 continue;
>                         }
>                         if (index == 0xaa || index == 0xb6)

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

Re: Re:Re: Linux 2.6.0-test4

[Ralf Hildebrandt]

* Chris Heath <chris@heathens.co.nz>:
> > Aug 27 18:53:41 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > Aug 27 19:15:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> > Aug 27 19:42:50 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > Aug 28 10:14:14 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> > 
> > Basically, CTRL was stuck. Even when I switched to X11.
> 
> Well, this completely baffles me.  I thought X11 maintains its own
> keydown array.
> 
> Anyway, I've included a patch that should hopefully give us better
> debugging information.  When you get an unknown key error, it will also
> dump the last 16 bytes that were sent from the keyboard.  Be careful
> with this one.  If you post any errors to the list, make sure it doesn't
> contain any sensitive passwords. :-)

I got some more events, and today I even was able to reproduc the
"CTRL-is-stuck" problem.

I was able to get the key unstuck by switching back and forth between
dirrerent FB consoles and by pushing and releaseing CTRL in them...

Sep  2 09:10:01 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
Sep  2 09:10:01 hummus2 kernel: i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c

Sep  2 09:10:06 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
Sep  2 09:10:06 hummus2 kernel: i8042 history: 1c 9c 1c 9c e0 50 e0 d0 e0 50 e0 d0 e0 d0 20 a0

Sep  2 09:14:54 hummus2 kernel: input: AT Set 2 keyboard on isa0060/serio0

Sep  2 09:25:44 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Sep  2 09:25:44 hummus2 kernel: i8042 history: e0 50 e0 d0 e0 50 e0 d0 e0 d0 1d 2d ad 1f 9f 9d

Sep  2 09:30:34 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
Sep  2 09:30:34 hummus2 kernel: i8042 history: e0 48 e0 c8 39 b9 e0 38 56 d6 e0 b8 e0 b8 39 b9

Sep  2 09:35:51 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
Sep  2 09:35:51 hummus2 kernel: i8042 history: a0 20 a0 9d e0 4d e0 cd e0 4d e0 cd e0 cd 39 b9

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

keyboard - was: Re: Linux 2.6.0-test4

[Andries Brouwer]

On Tue, Sep 02, 2003 at 10:07:33AM +0200, Ralf Hildebrandt wrote:

> I got some more events, and today I even was able to reproduc the
> "CTRL-is-stuck" problem.
> 
> I was able to get the key unstuck by switching back and forth between
> dirrerent FB consoles and by pushing and releaseing CTRL in them...

Yesterday's data sufficed, and I suppose the patch I gave solves
this problem. Now that you send this, we can verify that each time
there is a problem we have had a double release just before, and
that release was an e0 xx combination.

> atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c
> 
> atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
> i8042 history: 1c 9c 1c 9c e0 50 e0 d0 e0 50 e0 d0 e0 d0 20 a0
> 
> atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> i8042 history: e0 50 e0 d0 e0 50 e0 d0 e0 d0 1d 2d ad 1f 9f 9d
> 
> atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> i8042 history: e0 48 e0 c8 39 b9 e0 38 56 d6 e0 b8 e0 b8 39 b9
> 
> atkbd.c: Unknown key (set 2, scancode 0xb9, on isa0060/serio0) pressed.
> i8042 history: a0 20 a0 9d e0 4d e0 cd e0 4d e0 cd e0 cd 39 b9

And indeed, we see e0 d0 e0 d0, e0 b8 e0 b8, e0 cd e0 cd.

This bug is understood.

Re: keyboard - was: Re: Linux 2.6.0-test4

[Ralf Hildebrandt]

* Andries Brouwer <aebr@win.tue.nl>:
> On Tue, Sep 02, 2003 at 10:07:33AM +0200, Ralf Hildebrandt wrote:
> 
> > I got some more events, and today I even was able to reproduc the
> > "CTRL-is-stuck" problem.
> > 
> > I was able to get the key unstuck by switching back and forth between
> > dirrerent FB consoles and by pushing and releaseing CTRL in them...
> 
> Yesterday's data sufficed, and I suppose the patch I gave solves
> this problem. Now that you send this, we can verify that each time
> there is a problem we have had a double release just before, and
> that release was an e0 xx combination.

Excellent. I rebuild my kernel including your patch; I shall reboot
soon :)

> This bug is understood.

I'll get back to you once I verify that the problem doesn't occur
anymore.

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
* Andries Brouwer <aebr@win.tue.nl>:
> On Tue, Sep 02, 2003 at 10:07:33AM +0200, Ralf Hildebrandt wrote:
> 
> > I got some more events, and today I even was able to reproduc the
> > "CTRL-is-stuck" problem.
> > 
> > I was able to get the key unstuck by switching back and forth between
> > dirrerent FB consoles and by pushing and releaseing CTRL in them...
> 
> Yesterday's data sufficed, and I suppose the patch I gave solves
> this problem. Now that you send this, we can verify that each time
> there is a problem we have had a double release just before, and
> that release was an e0 xx combination.

Excellent. I rebuild my kernel including your patch; I shall reboot
soon :)

> This bug is understood.

I'll get back to you once I verify that the problem doesn't occur
anymore.

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

Re: keyboard - was: Re: Linux 2.6.0-test4

[Ralf Hildebrandt]

* Andries Brouwer <aebr@win.tue.nl>:

> Yesterday's data sufficed, and I suppose the patch I gave solves
> this problem.

Nope. I applied the patch and rebuilt the kernel and rebooted.

Linux version 2.6.0-test4-bk2 (root@hummus2) (gcc version 3.2.3 (Debian)) #1 Tue Sep 2 11:45:23 CEST 2003
shows that the kernel I build this moring is actually running.

Right now, my CTRL key is totally "stuck" on the fbconsole. I can't
release it, not even by switching between the consoles and/or X11.

But now I don't get any messages like the one below (yes, the special
code generating this output is still active...)

> > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
* Andries Brouwer <aebr@win.tue.nl>:

> Yesterday's data sufficed, and I suppose the patch I gave solves
> this problem.

Nope. I applied the patch and rebuilt the kernel and rebooted.

Linux version 2.6.0-test4-bk2 (root@hummus2) (gcc version 3.2.3 (Debian)) #1 Tue Sep 2 11:45:23 CEST 2003
shows that the kernel I build this moring is actually running.

Right now, my CTRL key is totally "stuck" on the fbconsole. I can't
release it, not even by switching between the consoles and/or X11.

But now I don't get any messages like the one below (yes, the special
code generating this output is still active...)

> > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

Re: keyboard - was: Re: Linux 2.6.0-test4

[Andries Brouwer]

On Tue, Sep 02, 2003 at 02:32:52PM +0200, Ralf Hildebrandt wrote:

> > Yesterday's data sufficed, and I suppose the patch I gave solves
> > this problem.
> 
> Nope. I applied the patch and rebuilt the kernel and rebooted.
> 
> Right now, my CTRL key is totally "stuck" on the fbconsole. I can't
> release it, not even by switching between the consoles and/or X11.
> 
> But now I don't get any messages like the one below (yes, the special
> code generating this output is still active...)
> 
> > > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c

Well, that shows that this particular problem was solved, but there are
more problems. No doubt we'll understand everything eventually.

(Unless we remove this i8042_unxlate_seen before understanding all problems.
It is really very ugly to have two different arrays that both keep the
"key down" status of the keys, and that can get out of sync.)

Again, of course, I would like to see the past few dozen scancodes, like you
gave before, up to the moment the problem arises.
(If you cannot think of something better, just log every incoming scancode.)

Andries

Re: keyboard - was: Re: Linux 2.6.0-test4

[Ralf Hildebrandt]

* Andries Brouwer <aebr@win.tue.nl>:

> > > > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > > > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c
> 
> Well, that shows that this particular problem was solved, but there are
> more problems. No doubt we'll understand everything eventually.

Thanks. And I'm happy to apply your patches to my shitty laptop :)
 
> (Unless we remove this i8042_unxlate_seen before understanding all problems.
> It is really very ugly to have two different arrays that both keep the
> "key down" status of the keys, and that can get out of sync.)
> 
> Again, of course, I would like to see the past few dozen scancodes, like you
> gave before, up to the moment the problem arises.
> (If you cannot think of something better, just log every incoming scancode.)

Right now I keep running the laptop with your patch and the keycode
history patch.

Anything in particular that I should do?

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

Re: keyboard - was: Re: Linux 2.6.0-test4

[Ralf Hildebrandt]

* Andries Brouwer <aebr@win.tue.nl>:

> Well, that shows that this particular problem was solved, but there are
> more problems. No doubt we'll understand everything eventually.
> 
> (Unless we remove this i8042_unxlate_seen before understanding all problems.
> It is really very ugly to have two different arrays that both keep the
> "key down" status of the keys, and that can get out of sync.)
> 
> Again, of course, I would like to see the past few dozen scancodes, like you
> gave before, up to the moment the problem arises.
> (If you cannot think of something better, just log every incoming scancode.)

Right now I'm building 2.6.0-test4-bk5 (which has "the patch" in it)
and added the keycode history patch. I'll let you know how it goes.

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt@charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix

Re: keyboard - was: Re: Linux 2.6.0-test4

[Andries Brouwer]

On Fri, Sep 05, 2003 at 03:57:57PM +0100, John Bradford wrote:

> My keyboard which requires Set 3 to operate fully sends a distinctive
> ID, so can be identified, and set to Set 3 automatically.

Aha - maybe you told me but then I failed to extract that bit of information.
What ID does your keyboard send?

Andries

http://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html#ss6.3

Re: keyboard - was: Re: Linux 2.6.0-test4

[John Bradford]

> > At this late stage, I don't think it is a good idea to completely
> > rewrite the untranslate algorithm.  So we continue to hack it and hack
> > it until it works.  :-/
>
> Surely not.  Some keyboards which worked since 2.0 and probably 1.something
> are broken in 2.6.

Aren't we over-complicating this?

The vast majority of keyboards are usable with translated Set 2, and
no workarounds.  Some workarounds may break other keyboards, possibly
ones we don't even know about yet.

There are advantages to using untranslated Set 2, and Set 3, and some
keyboards need to be used in those modes them to work correctly.

So, why not:

* Default to translated Set 2 with no work arounds, unless the
keyboard is known to work fine in Set 3.

Either:

1. It works perfectly.
2. It doesn't.

In case 1, if the user is happy with translated Set 2, there is no
problem.  If they are interested in seeing whether the technically
neater untranslated Set 2, or Set 3 work for them they can test them
and see.

In case 2, the user can boot with a kernel parameter enabling
workarounds for broken keyboards.  Conflicting workarounds can be
moved in to different sets, I.E. boot with inputworkarounds=1 for the
most common ones, and inputworkarounds=2 for the less common ones.

This should get almost all keyboards working by default.  Most of
those that don't work due to critical errors such as keys bouncing and
excessive auto-repeat, and those that don't work fully, should work
fully with workarounds enabled.

My keyboard which requires Set 3 to operate fully sends a distinctive
ID, so can be identified, and set to Set 3 automatically.

John.

Re: keyboard - was: Re: Linux 2.6.0-test4

[Norman Diamond]

Although I don't have time to keep up with the list, I saw this posting from
"Chris Heath" <chris@heathens.co.nz>.  Reordered by importance:

> At this late stage, I don't think it is a good idea to completely
> rewrite the untranslate algorithm.  So we continue to hack it and hack
> it until it works.  :-/

Surely not.  Some keyboards which worked since 2.0 and probably 1.something
are broken in 2.6.  Other keyboards which worked before 2.2.something
(without USB drivers but with BIOS emulation) and resumed working since
2.4.something (with fixed USB dirvers) are broken in 2.6.  Haven't some
lessons been learned from a 2.4.something-dontuse and a few other
2.4.somethings which also should have been -dontuse?  If 2.6.0-dontuse gets
released, Linux will really be as bad as some other famous operating
systems.  Surely it is better to rewrite the untranslate algorithm.

Of course there's some power management and other problems which are in the
same situation.  The keyboard is not the only reason why it would be foolish
to release 2.6.0 before it starts working.

> However, the bytes that come from the i8042 are a mixture of Set 1 and
> Set 2.  Set 1 because the key releases have their 8th bits set, and Set
> 2 because we get the non-XT keys escaped with E0.

I wonder if it's really that simple.  Though today I experimented on a
desktop machine which might have a real i8042 maybe.  Under a combination of
2.6.0-test4 and X11, showkey -s produced the same results which showkey -s
used to produce under 2.4.something on a plain text console.  Maybe this
proves that X11 still accesses the keyboard at a sufficiently low level that
it doesn't suffer from the breakage that was added in 2.6.0-test4 keyboard
drivers.

> I guess the keyboard is sending Set 2 and the BIOS is translating the set
> 2 codes to set 1 for "compatibility with XT software".

I'm pretty sure that this isn't that simple.  The BIOS fails to translate
some keys.  I hacked grub enough to make it possible to type from a Japanese
 keyboard into grub.  Fortunately grub doesn't use every key that the BIOS
understands, so I was able to swap some scan codes in grub's interrupt
handler, let the BIOS translate the ones it likes, and then translate the
results again in grub's higher-level translator.

(Now why does such ugly stuff make people want to puke on their keyboards
when it's really the BIOS's fault  :-?)

Re: keyboard - was: Re: Linux 2.6.0-test4

[Andries Brouwer]

On Thu, Sep 04, 2003 at 11:41:38PM -0400, Chris Heath wrote:

> Well... I think the overall design is the right one.  The atkbd driver
> expects to be talking to an AT keyboard, usually using Set 2.

Always be precise: there are six modes, namely
translated/untranslated Set 1/2/3.

By default every recent keyboard comes up in translated Set 2.
atkbd.c is broken, because it expects what the keyboard does not send,
namely untranslated Set 2.

{and here "send" is not defined as what bits are on some cable,
that is invisible for the programmer and varies between systems,
but as what bits get read by the kernel}

> However, the bytes that come from the i8042 are a mixture of Set 1 and
> Set 2.  Set 1 because the key releases have their 8th bits set, and Set
> 2 because we get the non-XT keys escaped with E0. I guess the keyboard
> is sending Set 2 and the BIOS is translating the set 2 codes to set 1
> for "compatibility with XT software".

There are several misunderstandings in this paragraph.
No, the BIOS is not involved - Linux does not use the BIOS,
except possibly at boot time.
Both translated and untranslated Set 2 use E0 prefixes,
and E0 is translated to E0.

The translation is done by the keyboard controller.
On many laptops the strange construction of a keyboard that sends
the wrong codes, which then are translated by a separate microprocessor,
is thrown out, and the keyboard directly produces the desired codes,
namely translated Set 2, and no translation happens.
Also the compatibility mode of USB only knows about translated Set 2.

> So the i8042 layer is IMHO the right place to untranslate this mess back
> into normal Set 2.

There is nothing normal about this untranslated Set 2.
It is a figment of the imagination.
Laptop hardware doesnt know anything about it.

> The problem is that the translation is not invertible

Yes, indeed, so we introduce some small bugs by doing this silly
untranslation.

> The current algorithm is to untranslate all bytes 0x00-0x7f, and to
> untranslate the others only if there was a previous key press.  This
> means the i8042 layer has to know about scancodes, knowledge which
> probably only belongs in the atkbd layer.

Yes, precisely.

> Probably, now that I think about it, the sanitization of duplicate key
> releases should rightfully be part of the atkbd layer, because those
> codes are actually being sent from the keyboard.

Yes, precisely.
And indeed, no sanitization is needed at all.

> But either way, the problem remains to find a good untranslate
> hack^Walgorithm.  Because we are getting duplicate key releases, we have
> to make sure they they are either untranslated or removed.  Sending them
> through unchanged, as we were in -test1 causes lots of grief to the
> atkbd layer.

But that is a bug in atkbd.

Andries

Re: keyboard - was: Re: Linux 2.6.0-test4

[Chris Heath]

> > Are you saying that it isn't possible for i8042.c to simply pass all
> > events (including duplicates) to the keyboard driver to sanitise?
> 
> I am saying that I would like nothing better than that.
> But it is a fundamental change of setup.

Well... I think the overall design is the right one.  The atkbd driver
expects to be talking to an AT keyboard, usually using Set 2.

However, the bytes that come from the i8042 are a mixture of Set 1 and
Set 2.  Set 1 because the key releases have their 8th bits set, and Set
2 because we get the non-XT keys escaped with E0. I guess the keyboard
is sending Set 2 and the BIOS is translating the set 2 codes to set 1
for "compatibility with XT software".

So the i8042 layer is IMHO the right place to untranslate this mess back
into normal Set 2.  The problem is that the BIOS translation is not
invertible, so we have to hack the untranslation as best we can.  The
current algorithm is to untranslate all bytes 0x00-0x7f, and to
untranslate the others only if there was a previous key press.  This
means the i8042 layer has to know about scancodes, knowledge which
probably only belongs in the atkbd layer.

Probably, now that I think about it, the sanitization of duplicate key
releases should rightfully be part of the atkbd layer, because those
codes are actually being sent from the keyboard.

But either way, the problem remains to find a good untranslate
hack^Walgorithm.  Because we are getting duplicate key releases, we have
to make sure they they are either untranslated or removed.  Sending them
through unchanged, as we were in -test1 causes lots of grief to the
atkbd layer.

At this late stage, I don't think it is a good idea to completely
rewrite the untranslate algorithm.  So we continue to hack it and hack
it until it works.  :-/

Chris

Re: keyboard - was: Re: Linux 2.6.0-test4

[Andries Brouwer]

On Fri, Sep 05, 2003 at 12:00:55AM +0100, Jamie Lokier wrote:

> Are you saying that it isn't possible for i8042.c to simply pass all
> events (including duplicates) to the keyboard driver to sanitise?

I am saying that I would like nothing better than that.
But it is a fundamental change of setup.

Re: keyboard - was: Re: Linux 2.6.0-test4

[Jamie Lokier]

Andries Brouwer wrote:
> Ha! We maintain two such bitmaps. And they get out of sync too.
> 
> You talk too easily. "If you receive a release event".
> But one does not receive release events, one receives bytes.
> The interpretation of those bytes belongs to the keyboard driver.
> 
> But i8042.c needs to know whether scancodes are releases
> in order to do its massaging of the scancodes before giving
> them to the keyboard driver.

Are you saying that it isn't possible for i8042.c to simply pass all
events (including duplicates) to the keyboard driver to sanitise?

-- Jamie

Re: keyboard - was: Re: Linux 2.6.0-test4

[Andries Brouwer]

On Thu, Sep 04, 2003 at 09:48:16PM +0100, Jamie Lokier wrote:

> Why so many complicated assumptions?  Just maintain a bitmap if key
> up/down states (initialised to up), and if you receive a release event
> when the key is in the up state, ignore the event.

Ha! We maintain two such bitmaps. And they get out of sync too.

You talk too easily. "If you receive a release event".
But one does not receive release events, one receives bytes.
The interpretation of those bytes belongs to the keyboard driver.

But i8042.c needs to know whether scancodes are releases
in order to do its massaging of the scancodes before giving
them to the keyboard driver.

I regard i8042.c as fundamentally broken.
On the other hand, it almost works.

Andries

Re: keyboard - was: Re: Linux 2.6.0-test4

[Jamie Lokier]

Chris Heath wrote:
> 1. I assume it is OK to defer processing the code e0 until the following
> byte arrives.  Are there any keyboards out there with e0 in the keyboard
> ID?  This could break the atkbd probe for such keyboards.  (The
> alternative would be to pass the repeated key releases through to atkbd,
> and let that layer remove the duplicates.)
> 
> 2. The event that appears between two repeated key releases is always a
> key release and not a key press.
> 
> 3. There will only be at most one key event in between two repeated key 
> releases.

Why so many complicated assumptions?  Just maintain a bitmap if key
up/down states (initialised to up), and if you receive a release event
when the key is in the up state, ignore the event.

-- Jamie

Re: keyboard - was: Re: Linux 2.6.0-test4

[Chris Heath]

> > Right now, my CTRL key is totally "stuck" on the fbconsole. I can't
> > release it, not even by switching between the consoles and/or X11.
> > 
> > > > atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
> > > > i8042 history: e0 d0 1c 9c 2e ae 10 90 e0 50 e0 d0 e0 d0 1c 9c
> 
> Well, that shows that this particular problem was solved, but there are
> more problems. No doubt we'll understand everything eventually.

Quite right.  When we get a repeated key release, say e0 d0 e0 d0, we
were ignoring the last d0, whereas actually we should have ignored the
second e0 too.  As you can imagine, this caused stuck CTRL keys among
other things.

> > But now I don't get any messages like the one below (yes, the special
> > code generating this output is still active...)

Since then, Ralf has reported to me in a private email that he got the
following (rather troubling) error:

Sep  2 14:43:51 hummus2 kernel: atkbd.c: Unknown key (set 2, scancode 0xb2, on isa0060/serio0) pressed.
Sep  2 14:43:51 hummus2 kernel: i8042 history: e0 48 e0 c8 22 a2 13 93 93 17 97 32 31 b2 b1 b2

So it seems it is occasionally possible to have a repeated key release
(b2) with another key release (b1) in between.  Ouch!

The patch below is supposed to solve both these problems.  It makes some 
assumptions, which I have listed below.  (It probably wouldn't be hard to 
remove any of these assumptions, but I don't feel like hacking this
code any more than I have to.)

1. I assume it is OK to defer processing the code e0 until the following
byte arrives.  Are there any keyboards out there with e0 in the keyboard
ID?  This could break the atkbd probe for such keyboards.  (The
alternative would be to pass the repeated key releases through to atkbd,
and let that layer remove the duplicates.)

2. The event that appears between two repeated key releases is always a
key release and not a key press.

3. There will only be at most one key event in between two repeated key 
releases.

Chris


--- linux-2.6.0-test4-bk5/drivers/input/serio/i8042.c	2003-08-09 11:58:10.000000000 -0400
+++ linux-2.6.0-test4-cdh1/drivers/input/serio/i8042.c	2003-09-03 22:30:52.000000000 -0400
@@ -59,7 +59,7 @@
 static unsigned char i8042_initial_ctr;
 static unsigned char i8042_ctr;
 static unsigned char i8042_last_e0;
-static unsigned char i8042_last_release;
+static unsigned char i8042_last_release[2];
 static unsigned char i8042_mux_open;
 struct timer_list i8042_timer;
 
@@ -343,7 +343,7 @@
 static irqreturn_t i8042_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
 	unsigned long flags;
-	unsigned char str, data;
+	unsigned char str, data, index;
 	unsigned int dfl;
 	struct {
 		int data;
@@ -405,30 +405,39 @@
 			continue;
 		}
 
+		index = (data & 0x7f) | (i8042_last_e0 << 7);
+
+		/* work around hardware that doubles key releases */
+		if (data > 0x7f && (index == i8042_last_release[0]
+				|| index == i8042_last_release[1])) {
+			dbg("i8042 skipped double release (%d)\n", index);
+			i8042_last_e0 = 0;
+			continue;
+		}
+
+		if (i8042_last_e0)
+			serio_interrupt(&i8042_kbd_port, 0xe0, dfl, regs);
 		if (data > 0x7f) {
-			unsigned char index = (data & 0x7f) | (i8042_last_e0 << 7);
-			/* work around hardware that doubles key releases */
-			if (index == i8042_last_release) {
-				dbg("i8042 skipped double release (%d)\n", index);
-				i8042_last_e0 = 0;
-				continue;
-			}
 			if (index == 0xaa || index == 0xb6)
 				set_bit(index, i8042_unxlate_seen);
 			if (test_and_clear_bit(index, i8042_unxlate_seen)) {
 				serio_interrupt(&i8042_kbd_port, 0xf0, dfl, regs);
 				data = i8042_unxlate_table[data & 0x7f];
-				i8042_last_release = index;
+				i8042_last_release[1] = i8042_last_release[0];
+				i8042_last_release[0] = index;
 			}
 		} else {
-			set_bit(data | (i8042_last_e0 << 7), i8042_unxlate_seen);
+			set_bit(index, i8042_unxlate_seen);
 			data = i8042_unxlate_table[data];
-			i8042_last_release = 0;
+			i8042_last_release[1] = 0;
+			i8042_last_release[0] = 0;
 		}
 
 		i8042_last_e0 = (data == 0xe0);
 
-		serio_interrupt(&i8042_kbd_port, data, dfl, regs);
+		/* defer sending e0 in case it's part of a double key release */
+		if (!i8042_last_e0)
+			serio_interrupt(&i8042_kbd_port, data, dfl, regs);
 	}
 
 	/* FIXME - was it really ours? */