* i8042 problem
@ 2003-07-26 6:11 Pete Zaitcev
2003-07-26 9:36 ` Andries Brouwer
0 siblings, 1 reply; 19+ messages in thread
From: Pete Zaitcev @ 2003-07-26 6:11 UTC (permalink / raw)
To: vojtech; +Cc: linux-kernel, zaitcev
Hi, Vojtech:
On my old laptop, i8042 refuses to work with 2.6.0-test1-bk2.
After a reboot, keyboard is dead. Hooking external keyboard
revives the internal keyboard. Here's the dmesg with DEBUG:
Linux version 2.6.0-test1-bk2 (zaitcev@niphredil) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #6 Fri Jul 25 20:28:14 PDT 2003
...
Kernel command line: ro root=/dev/hda1 vga=0x0f05 console=ttyS0,38400
...
hda: 2822400 sectors (1445 MB) w/96KiB Cache, CHS=2800/16/63
hda: hda1 hda2 hda3
drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
drivers/input/serio/i8042.c: 45 <- i8042 (return) [0]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [1]
drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [1]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [2]
drivers/input/serio/i8042.c: f0 -> i8042 (parameter) [2]
drivers/input/serio/i8042.c: 0f <- i8042 (return) [2]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [2]
drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [2]
drivers/input/serio/i8042.c: a9 <- i8042 (return) [2]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [3]
drivers/input/serio/i8042.c: a4 -> i8042 (parameter) [3]
drivers/input/serio/i8042.c: 5b <- i8042 (return) [3]
drivers/input/serio/i8042.c: d3 -> i8042 (command) [4]
drivers/input/serio/i8042.c: 5a -> i8042 (parameter) [4]
drivers/input/serio/i8042.c: a5 <- i8042 (return) [4]
drivers/input/serio/i8042.c: a7 -> i8042 (command) [4]
drivers/input/serio/i8042.c: 20 -> i8042 (command) [5]
drivers/input/serio/i8042.c: 74 <- i8042 (return) [5]
drivers/input/serio/i8042.c: a8 -> i8042 (command) [5]
drivers/input/serio/i8042.c: 20 -> i8042 (command) [5]
drivers/input/serio/i8042.c: 54 <- i8042 (return) [5]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [6]
drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [6]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [6]
drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [6]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [8]
drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [8]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [8]
drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [8]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [11]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [13]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [13]
drivers/input/serio/i8042.c: 54 -> i8042 (parameter) [13]
serio: i8042 AUX port at 0x60,0x64 irq 12
drivers/input/serio/i8042.c: 60 -> i8042 (command) [26]
drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [26]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [28]
drivers/input/serio/i8042.c: 45 -> i8042 (parameter) [28]
drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [28]
drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [38]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [40]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [40]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]
drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
serio: i8042 KBD port at 0x60,0x64 irq 1
NET4: Linux TCP/IP 1.0 for NET4.0
<------------- This is it, keyboard is dead.
.......
V---- Trying to hook external keyboard now
drivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 0) [109588]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [109613]
drivers/input/serio/i8042.c: 45 -> i8042 (parameter) [109613]
drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [109614]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109619]
drivers/input/serio/i8042.c: ab <- i8042 (interrupt, kbd, 1) [109639]
drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109660]
drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [109680]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109687]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [109708]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109714]
drivers/input/serio/i8042.c: f8 -> i8042 (kbd-data) [109735]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109742]
drivers/input/serio/i8042.c: f4 -> i8042 (kbd-data) [109763]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109770]
drivers/input/serio/i8042.c: f0 -> i8042 (kbd-data) [109790]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109797]
drivers/input/serio/i8042.c: 02 -> i8042 (kbd-data) [109818]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109825]
drivers/input/serio/i8042.c: f0 -> i8042 (kbd-data) [109846]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109852]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [109873]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109879]
drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109900]
drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109921]
atkbd.c: Unknown key (set 0, scancode 0x2, on isa0060/serio0) pressed.
input: AT Set 2 keyboard on isa0060/serio0
<----- Now we are talking!
Any ideas?
-- Pete
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-26 6:11 i8042 problem Pete Zaitcev
@ 2003-07-26 9:36 ` Andries Brouwer
2003-07-27 1:41 ` Chris Heath
0 siblings, 1 reply; 19+ messages in thread
From: Andries Brouwer @ 2003-07-26 9:36 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: vojtech, linux-kernel
On Sat, Jul 26, 2003 at 02:11:36AM -0400, Pete Zaitcev wrote:
> On my old laptop, i8042 refuses to work with 2.6.0-test1-bk2.
> After a reboot, keyboard is dead. Hooking external keyboard
> revives the internal keyboard. Here's the dmesg with DEBUG:
>
> drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]
> drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]
> drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
> serio: i8042 KBD port at 0x60,0x64 irq 1
> <------------- This is it, keyboard is dead.
Writing 44 to the command byte disables IRQ1.
(Otherwise the only remarkable part was that no reaction came to
f2 - identify keyboard.)
> V---- Trying to hook external keyboard now
> drivers/input/serio/i8042.c: f0 -> i8042 (kbd-data) [109846]
> drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109852]
> drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [109873]
> drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [109879]
> drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109900]
> drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109921]
> atkbd.c: Unknown key (set 0, scancode 0x2, on isa0060/serio0) pressed.
> input: AT Set 2 keyboard on isa0060/serio0
> <----- Now we are talking!
Funny. Looks like the "read scancode set" command got the scancode set
twice, and the second time was seen as unknown key.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-26 9:36 ` Andries Brouwer
@ 2003-07-27 1:41 ` Chris Heath
2003-07-27 6:06 ` Pete Zaitcev
0 siblings, 1 reply; 19+ messages in thread
From: Chris Heath @ 2003-07-27 1:41 UTC (permalink / raw)
To: aebr; +Cc: zaitcev, linux-kernel
> > drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [40]
> > drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]
> > drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]
> > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
> > serio: i8042 KBD port at 0x60,0x64 irq 1
> > <------------- This is it, keyboard is dead.
>
>
> Writing 44 to the command byte disables IRQ1.
It looks like a timeout problem. The ack (fa) arrived 11 ticks after
the byte (00) was sent, but it looks like the timeout is only 10 ticks.
Try playing with the timeout in atkbd_sendbyte (line 217 of
drivers/input/keyboard/atkbd.c).
> > drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109900]
> > drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [109921]
> > atkbd.c: Unknown key (set 0, scancode 0x2, on isa0060/serio0) pressed.
> > input: AT Set 2 keyboard on isa0060/serio0
> > <----- Now we are talking!
>
>
> Funny. Looks like the "read scancode set" command got the scancode set
> twice, and the second time was seen as unknown key.
Both keyboards responded to the command, perhaps???
I'd suggest that we don't even ask the keyboard what scancode set it is
using if we are attempting to use set 2.
Chris
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-27 1:41 ` Chris Heath
@ 2003-07-27 6:06 ` Pete Zaitcev
2003-07-27 10:47 ` Andries Brouwer
0 siblings, 1 reply; 19+ messages in thread
From: Pete Zaitcev @ 2003-07-27 6:06 UTC (permalink / raw)
To: Chris Heath; +Cc: aebr, zaitcev, linux-kernel
> Date: Sat, 26 Jul 2003 21:41:32 -0400
> From: Chris Heath <chris@heathens.co.nz>
> > > drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [40]
> > > drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]
> > > drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]
> > > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
> > > serio: i8042 KBD port at 0x60,0x64 irq 1
> > > <------------- This is it, keyboard is dead.
> >
> > Writing 44 to the command byte disables IRQ1.
>
> It looks like a timeout problem. The ack (fa) arrived 11 ticks after
> the byte (00) was sent, but it looks like the timeout is only 10 ticks.
>
> Try playing with the timeout in atkbd_sendbyte (line 217 of
> drivers/input/keyboard/atkbd.c).
Playing with timeout does not help, but on second thought
I suspect that atkbd fails to open the port for some reason,
that's why interrupts stay disabled.
-- Pete
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-27 6:06 ` Pete Zaitcev
@ 2003-07-27 10:47 ` Andries Brouwer
2003-07-28 1:55 ` Pete Zaitcev
2003-08-12 20:42 ` Vojtech Pavlik
0 siblings, 2 replies; 19+ messages in thread
From: Andries Brouwer @ 2003-07-27 10:47 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Chris Heath, linux-kernel
On Sun, Jul 27, 2003 at 02:06:21AM -0400, Pete Zaitcev wrote:
> > Date: Sat, 26 Jul 2003 21:41:32 -0400
> > From: Chris Heath <chris@heathens.co.nz>
>
> > > > drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [40]
> > > > drivers/input/serio/i8042.c: 60 -> i8042 (command) [50]
> > > > drivers/input/serio/i8042.c: 44 -> i8042 (parameter) [50]
> > > > drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [51]
> > > > serio: i8042 KBD port at 0x60,0x64 irq 1
> > > > <------------- This is it, keyboard is dead.
> > >
> > > Writing 44 to the command byte disables IRQ1.
> >
> > It looks like a timeout problem. The ack (fa) arrived 11 ticks after
> > the byte (00) was sent, but it looks like the timeout is only 10 ticks.
> >
> > Try playing with the timeout in atkbd_sendbyte (line 217 of
> > drivers/input/keyboard/atkbd.c).
>
> Playing with timeout does not help, but on second thought
> I suspect that atkbd fails to open the port for some reason,
> that's why interrupts stay disabled.
Well, Chris is right, of course.
As I said, writing 44 to the command byte disables IRQ1.
So, the question is, who does that. Read the code:
We do i8042_init, detect a PS/2 keyboard/mouse controller, and call
i8042_port_register() first for mouse, then for keyboard.
This i8042_port_register() does
serio_register_port(port);
and then happily reports
printk(KERN_INFO "serio: i8042 %s port at %#lx,%#lx irq %d\n"
This serio_register_port(port) probes connected devices.
It calls atkbd_connect(), which calls atkbd_probe(), and
the latter fails.
Now atkbd_connect() does serio_close() which does
i8042_close() and we see
i8042_ctr &= ~values->irqen;
i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR);
that the IRQ is disabled.
So the culprit is the failing of atkbd_probe().
It does a ATKBD_CMD_GETID, but gets no answer, then a
ATKBD_CMD_SETLEDS, and that command fails.
It sends the 0xed, gets an ACK, sends the 0x00 and times out.
And it times out because atkbd_sendbyte has a timeout of 10 msec
while the reply came after 11 msec.
So, apart from other things you might try, it seems to me that
changing the timeout in atkbd_sendbyte from the 10000 that is
there to the 100000 that the comment implies, should help.
Andries
- int timeout = 10000; /* 100 msec */
+ int timeout = 100000; /* 100 msec */
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-27 10:47 ` Andries Brouwer
@ 2003-07-28 1:55 ` Pete Zaitcev
2003-07-28 11:25 ` Alan Cox
2003-08-12 20:42 ` Vojtech Pavlik
1 sibling, 1 reply; 19+ messages in thread
From: Pete Zaitcev @ 2003-07-28 1:55 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Pete Zaitcev, Chris Heath, linux-kernel
> Date: Sun, 27 Jul 2003 12:47:26 +0200
> From: Andries Brouwer <aebr@win.tue.nl>
> So the culprit is the failing of atkbd_probe().
> It does a ATKBD_CMD_GETID, but gets no answer, then a
> ATKBD_CMD_SETLEDS, and that command fails.
I see the light now. Somehow I imagined that atkbd code does not call
the ->open for the port. Now it all falls into place. Everything works
with a bigger timeout.
Thanks a lot, Andries & Chris!
-- Pete
diff -urN -X dontdiff linux-2.6.0-test1-bk2/drivers/input/keyboard/atkbd.c linux-2.6.0-test1-bk2-nip/drivers/input/keyboard/atkbd.c
--- linux-2.6.0-test1-bk2/drivers/input/keyboard/atkbd.c 2003-07-13 20:37:15.000000000 -0700
+++ linux-2.6.0-test1-bk2-nip/drivers/input/keyboard/atkbd.c 2003-07-27 15:20:35.000000000 -0700
@@ -214,7 +214,7 @@
static int atkbd_sendbyte(struct atkbd *atkbd, unsigned char byte)
{
- int timeout = 10000; /* 100 msec */
+ int timeout = 20000; /* 200 msec */
atkbd->ack = 0;
#ifdef ATKBD_DEBUG
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 1:55 ` Pete Zaitcev
@ 2003-07-28 11:25 ` Alan Cox
2003-07-28 11:59 ` Andries Brouwer
2003-07-28 16:07 ` Pete Zaitcev
0 siblings, 2 replies; 19+ messages in thread
From: Alan Cox @ 2003-07-28 11:25 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Andries Brouwer, Chris Heath, Linux Kernel Mailing List
On Llu, 2003-07-28 at 02:55, Pete Zaitcev wrote:
> > Date: Sun, 27 Jul 2003 12:47:26 +0200
> > From: Andries Brouwer <aebr@win.tue.nl>
>
> > So the culprit is the failing of atkbd_probe().
> > It does a ATKBD_CMD_GETID, but gets no answer, then a
> > ATKBD_CMD_SETLEDS, and that command fails.
>
> I see the light now. Somehow I imagined that atkbd code does not call
> the ->open for the port. Now it all falls into place. Everything works
> with a bigger timeout.
Unfortunately with this change several people still report failures
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 11:25 ` Alan Cox
@ 2003-07-28 11:59 ` Andries Brouwer
2003-07-28 14:01 ` Maciej W. Rozycki
2003-07-28 16:07 ` Pete Zaitcev
1 sibling, 1 reply; 19+ messages in thread
From: Andries Brouwer @ 2003-07-28 11:59 UTC (permalink / raw)
To: Alan Cox; +Cc: Pete Zaitcev, Chris Heath, Linux Kernel Mailing List
On Mon, Jul 28, 2003 at 12:25:05PM +0100, Alan Cox wrote:
> On Llu, 2003-07-28 at 02:55, Pete Zaitcev wrote:
> > > Date: Sun, 27 Jul 2003 12:47:26 +0200
> > > From: Andries Brouwer <aebr@win.tue.nl>
> >
> > > So the culprit is the failing of atkbd_probe().
> > > It does a ATKBD_CMD_GETID, but gets no answer, then a
> > > ATKBD_CMD_SETLEDS, and that command fails.
> >
> > I see the light now. Somehow I imagined that atkbd code does not call
> > the ->open for the port. Now it all falls into place. Everything works
> > with a bigger timeout.
>
> Unfortunately with this change several people still report failures
Ach. One bug fixed and the Linux kernel is still not perfect?
What a pity.
[But yes, as I also said to someone else: on i386 one has a working
keyboard after bootup. No initialization and no probing required.
The new keyboard code uses a lot of knowledge about common keyboards
and keyboard controllers. It works in most cases. But already the
linux-kernel readers see a long stream of problems. I am afraid of
the effect on a million Linux users.]
[[On the other hand, as I wrote somewhere else, this is a great way
to learn a lot about very obscure keyboards.]]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 11:59 ` Andries Brouwer
@ 2003-07-28 14:01 ` Maciej W. Rozycki
2003-07-28 14:54 ` Andries Brouwer
0 siblings, 1 reply; 19+ messages in thread
From: Maciej W. Rozycki @ 2003-07-28 14:01 UTC (permalink / raw)
To: Andries Brouwer
Cc: Alan Cox, Pete Zaitcev, Chris Heath, Linux Kernel Mailing List
On Mon, 28 Jul 2003, Andries Brouwer wrote:
> On Mon, Jul 28, 2003 at 12:25:05PM +0100, Alan Cox wrote:
> > On Llu, 2003-07-28 at 02:55, Pete Zaitcev wrote:
> > >
> > > I see the light now. Somehow I imagined that atkbd code does not call
> > > the ->open for the port. Now it all falls into place. Everything works
> > > with a bigger timeout.
> >
> > Unfortunately with this change several people still report failures
>
> Ach. One bug fixed and the Linux kernel is still not perfect?
> What a pity.
>
> [But yes, as I also said to someone else: on i386 one has a working
> keyboard after bootup. No initialization and no probing required.
> The new keyboard code uses a lot of knowledge about common keyboards
> and keyboard controllers. It works in most cases. But already the
> linux-kernel readers see a long stream of problems. I am afraid of
> the effect on a million Linux users.]
Well, are timeouts needed at all, except for a single initial command to
see if a device is there? I would imagine the keyboard to be initialized
using an interrupt-driven state machine.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 14:01 ` Maciej W. Rozycki
@ 2003-07-28 14:54 ` Andries Brouwer
2003-07-28 15:43 ` Maciej W. Rozycki
0 siblings, 1 reply; 19+ messages in thread
From: Andries Brouwer @ 2003-07-28 14:54 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Alan Cox, Pete Zaitcev, Chris Heath, Linux Kernel Mailing List
On Mon, Jul 28, 2003 at 04:01:27PM +0200, Maciej W. Rozycki wrote:
> Well, are timeouts needed at all?
Yes. We send a command to the keyboard. It may react, or it may not.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 14:54 ` Andries Brouwer
@ 2003-07-28 15:43 ` Maciej W. Rozycki
2003-07-28 15:51 ` Andries Brouwer
0 siblings, 1 reply; 19+ messages in thread
From: Maciej W. Rozycki @ 2003-07-28 15:43 UTC (permalink / raw)
To: Andries Brouwer
Cc: Alan Cox, Pete Zaitcev, Chris Heath, Linux Kernel Mailing List
On Mon, 28 Jul 2003, Andries Brouwer wrote:
> > Well, are timeouts needed at all?
>
> Yes. We send a command to the keyboard. It may react, or it may not.
But we need not wait for that actively. If we are unsure about a result
of a command, then we may send a command in question followed with an echo
request. This assures an IRQ will finally arrive and if no command
response arrives before an echo response, then the keyboard ignored the
command. I used this approach many years ago to differ between PS/2
keyboards (which respond with 0xfa,0xab,0x83 to a request for ID) and
genuine PC/AT ones (which respond with lone 0xfa). It worked.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 15:43 ` Maciej W. Rozycki
@ 2003-07-28 15:51 ` Andries Brouwer
2003-07-29 18:29 ` Maciej W. Rozycki
0 siblings, 1 reply; 19+ messages in thread
From: Andries Brouwer @ 2003-07-28 15:51 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Alan Cox, Pete Zaitcev, Chris Heath, Linux Kernel Mailing List
On Mon, Jul 28, 2003 at 05:43:51PM +0200, Maciej W. Rozycki wrote:
> On Mon, 28 Jul 2003, Andries Brouwer wrote:
>
> > > Well, are timeouts needed at all?
> >
> > Yes. We send a command to the keyboard. It may react, or it may not.
>
> But we need not wait for that actively. If we are unsure about a result
> of a command, then we may send a command in question followed with an echo
> request. This assures an IRQ will finally arrive and if no command
> response arrives before an echo response, then the keyboard ignored the
> command. I used this approach many years ago to differ between PS/2
> keyboards (which respond with 0xfa,0xab,0x83 to a request for ID) and
> genuine PC/AT ones (which respond with lone 0xfa). It worked.
And what did you do for XT? :-)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 11:25 ` Alan Cox
2003-07-28 11:59 ` Andries Brouwer
@ 2003-07-28 16:07 ` Pete Zaitcev
2003-08-12 20:47 ` Vojtech Pavlik
1 sibling, 1 reply; 19+ messages in thread
From: Pete Zaitcev @ 2003-07-28 16:07 UTC (permalink / raw)
To: Alan Cox
Cc: Pete Zaitcev, Andries Brouwer, Chris Heath, Linux Kernel Mailing List
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: 28 Jul 2003 12:25:05 +0100
> > > So the culprit is the failing of atkbd_probe().
> > > It does a ATKBD_CMD_GETID, but gets no answer, then a
> > > ATKBD_CMD_SETLEDS, and that command fails.
> >
> > I see the light now. Somehow I imagined that atkbd code does not call
> > the ->open for the port. Now it all falls into place. Everything works
> > with a bigger timeout.
>
> Unfortunately with this change several people still report failures
I'm afraid it is to be expected. They have to go through the
motions of setting DEBUG. Unfortunately, it's not all that
simple. Messages scroll up and since the keyboard is dead,
they cannot be returned with Shift-PgUp. I used a serial console.
I think it's more effort most people are prepared to spend.
-- Pete
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 15:51 ` Andries Brouwer
@ 2003-07-29 18:29 ` Maciej W. Rozycki
2003-08-12 20:46 ` Vojtech Pavlik
0 siblings, 1 reply; 19+ messages in thread
From: Maciej W. Rozycki @ 2003-07-29 18:29 UTC (permalink / raw)
To: Andries Brouwer
Cc: Alan Cox, Pete Zaitcev, Chris Heath, Linux Kernel Mailing List
On Mon, 28 Jul 2003, Andries Brouwer wrote:
> > > > Well, are timeouts needed at all?
> > >
> > > Yes. We send a command to the keyboard. It may react, or it may not.
> >
> > But we need not wait for that actively. If we are unsure about a result
> > of a command, then we may send a command in question followed with an echo
> > request. This assures an IRQ will finally arrive and if no command
> > response arrives before an echo response, then the keyboard ignored the
> > command. I used this approach many years ago to differ between PS/2
> > keyboards (which respond with 0xfa,0xab,0x83 to a request for ID) and
> > genuine PC/AT ones (which respond with lone 0xfa). It worked.
>
> And what did you do for XT? :-)
Nice joke, but I'll answer seriously. No support was provided. Hooking
a PC/XT keyboard to the 8042, if supported, requires a different setup of
the command byte and is possibly done by the system firmware. You can
read the command byte to see which configuration is used.
Wrt polling vs IRQ-driven probing and setup: using IRQ is a natural
choice as you have to do keyboard detection in the IRQ handler anyway to
properly support hot plugging of a PC/AT or a PS/2 keyboard.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-27 10:47 ` Andries Brouwer
2003-07-28 1:55 ` Pete Zaitcev
@ 2003-08-12 20:42 ` Vojtech Pavlik
2003-08-12 23:06 ` Andries Brouwer
1 sibling, 1 reply; 19+ messages in thread
From: Vojtech Pavlik @ 2003-08-12 20:42 UTC (permalink / raw)
To: Andries Brouwer; +Cc: Pete Zaitcev, Chris Heath, linux-kernel
On Sun, Jul 27, 2003 at 12:47:26PM +0200, Andries Brouwer wrote:
> So, apart from other things you might try, it seems to me that
> changing the timeout in atkbd_sendbyte from the 10000 that is
> there to the 100000 that the comment implies, should help.
>
> Andries
>
>
> - int timeout = 10000; /* 100 msec */
> + int timeout = 100000; /* 100 msec */
Note that we do udelay(10) in the loop, so with this change you're
waiting for a whole second. The timeout might need to be made bigger,
but not that much.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-29 18:29 ` Maciej W. Rozycki
@ 2003-08-12 20:46 ` Vojtech Pavlik
2003-08-13 13:44 ` Maciej W. Rozycki
0 siblings, 1 reply; 19+ messages in thread
From: Vojtech Pavlik @ 2003-08-12 20:46 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Andries Brouwer, Alan Cox, Pete Zaitcev, Chris Heath,
Linux Kernel Mailing List
On Tue, Jul 29, 2003 at 08:29:01PM +0200, Maciej W. Rozycki wrote:
> Nice joke, but I'll answer seriously. No support was provided. Hooking
> a PC/XT keyboard to the 8042, if supported, requires a different setup of
> the command byte and is possibly done by the system firmware. You can
> read the command byte to see which configuration is used.
>
> Wrt polling vs IRQ-driven probing and setup: using IRQ is a natural
> choice as you have to do keyboard detection in the IRQ handler anyway to
> properly support hot plugging of a PC/AT or a PS/2 keyboard.
The only problem there is that it results in a damn complex state
machine. Look at the PS/2 mouse probing and imagine how the state
machine would look.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-07-28 16:07 ` Pete Zaitcev
@ 2003-08-12 20:47 ` Vojtech Pavlik
0 siblings, 0 replies; 19+ messages in thread
From: Vojtech Pavlik @ 2003-08-12 20:47 UTC (permalink / raw)
To: Pete Zaitcev
Cc: Alan Cox, Andries Brouwer, Chris Heath, Linux Kernel Mailing List
On Mon, Jul 28, 2003 at 12:07:43PM -0400, Pete Zaitcev wrote:
> > From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > Date: 28 Jul 2003 12:25:05 +0100
>
> > > > So the culprit is the failing of atkbd_probe().
> > > > It does a ATKBD_CMD_GETID, but gets no answer, then a
> > > > ATKBD_CMD_SETLEDS, and that command fails.
> > >
> > > I see the light now. Somehow I imagined that atkbd code does not call
> > > the ->open for the port. Now it all falls into place. Everything works
> > > with a bigger timeout.
> >
> > Unfortunately with this change several people still report failures
>
> I'm afraid it is to be expected. They have to go through the
> motions of setting DEBUG. Unfortunately, it's not all that
> simple. Messages scroll up and since the keyboard is dead,
> they cannot be returned with Shift-PgUp. I used a serial console.
> I think it's more effort most people are prepared to spend.
An USB keyboard can be very helpful in that case. Or a remote login.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-08-12 20:42 ` Vojtech Pavlik
@ 2003-08-12 23:06 ` Andries Brouwer
0 siblings, 0 replies; 19+ messages in thread
From: Andries Brouwer @ 2003-08-12 23:06 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Andries Brouwer, Pete Zaitcev, Chris Heath, linux-kernel
On Tue, Aug 12, 2003 at 10:42:46PM +0200, Vojtech Pavlik wrote:
> > - int timeout = 10000; /* 100 msec */
> > + int timeout = 100000; /* 100 msec */
>
> Note that we do udelay(10) in the loop,
Right.
Pete Zaitcev made it 20000 (since he needed 11000).
That seems reasonable.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: i8042 problem
2003-08-12 20:46 ` Vojtech Pavlik
@ 2003-08-13 13:44 ` Maciej W. Rozycki
0 siblings, 0 replies; 19+ messages in thread
From: Maciej W. Rozycki @ 2003-08-13 13:44 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Andries Brouwer, Alan Cox, Pete Zaitcev, Chris Heath,
Linux Kernel Mailing List
On Tue, 12 Aug 2003, Vojtech Pavlik wrote:
> > Wrt polling vs IRQ-driven probing and setup: using IRQ is a natural
> > choice as you have to do keyboard detection in the IRQ handler anyway to
> > properly support hot plugging of a PC/AT or a PS/2 keyboard.
>
> The only problem there is that it results in a damn complex state
> machine. Look at the PS/2 mouse probing and imagine how the state
> machine would look.
Well, I don't think a complex state machine is needed. What's the
variable part of the initialization? Essentially the keyboard type (two
options available) and the scancode mode selected (three options
available). Everything else is constant. So besides the current
initialization step, you only need to record these two variables. And the
good news is the more complicated setup scenarios are simply a superset of
the simpler ones, so you do not have multiple paths in the initialization
-- there's only one, of which parts are skipped, depending on the
configuration. Specifically, for a PC/AT keyboard you don't select a
scancode mode and for the PS/2 keyboard you don't set up key
up/down/repeat characteristics in modes #1 and #2.
Still if you go beyond the standard PC/XT compatibility mode, you need to
handle run-time keyboard switching, i.e. if I boot with a PS/2 keyboard,
unplug it and later use a PC/AT one, it should just work. I have a
similar problem with the LK201 keyboard driver (that's a standard DEC
keyboard implementation for a lot of their systems). There are different
keyboards having the same interface as the LK201 -- programming them is
the same, but their features differ, including the interpretation of some
keys and LEDs (the number of LEDs varies from 2 to 4 and they may have
different labels). For 2.4, the driver does a reasonable job of run-time
configuration, but it may still be improved (e.g. it doesn't yet do a
handshake I'm thinking of; unfortunately not all LK201 commands return an
ACK) and I'm planning to do that for 2.6. While looking at it, I may look
at the PS/2 driver and see how it can be improved.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2003-08-13 13:44 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-26 6:11 i8042 problem Pete Zaitcev
2003-07-26 9:36 ` Andries Brouwer
2003-07-27 1:41 ` Chris Heath
2003-07-27 6:06 ` Pete Zaitcev
2003-07-27 10:47 ` Andries Brouwer
2003-07-28 1:55 ` Pete Zaitcev
2003-07-28 11:25 ` Alan Cox
2003-07-28 11:59 ` Andries Brouwer
2003-07-28 14:01 ` Maciej W. Rozycki
2003-07-28 14:54 ` Andries Brouwer
2003-07-28 15:43 ` Maciej W. Rozycki
2003-07-28 15:51 ` Andries Brouwer
2003-07-29 18:29 ` Maciej W. Rozycki
2003-08-12 20:46 ` Vojtech Pavlik
2003-08-13 13:44 ` Maciej W. Rozycki
2003-07-28 16:07 ` Pete Zaitcev
2003-08-12 20:47 ` Vojtech Pavlik
2003-08-12 20:42 ` Vojtech Pavlik
2003-08-12 23:06 ` Andries Brouwer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).