(In reply to Benjamin Tissoires from comment #103)
> (In reply to Mateusz Jończyk from comment #102)
> What I read in case the touchpad is not working is that no one is trying to
> read from it. The irq might not be even requested, so no one can get events
> from it. It might be a command missing, but to me the problem lies after the
> i8042 controller has been initilized.
>
The IRQ is delivered and this is confirmed when the laptop does not work.
[ 1.327225] i8042: [2] 20 -> i8042 (command)
[ 1.327448] i8042: [2] 54 <- i8042 (return)
[ 1.327471] i8042: [2] 60 -> i8042 (command)
[ 1.327530] i8042: [2] 56 -> i8042 (parameter)
[ 1.327644] i8042: [2] d3 -> i8042 (command)
[ 1.327757] i8042: [2] a5 -> i8042 (parameter)
[ 1.327995] i8042: [3] a5 <- i8042 (aux_test_irq, aux)
[ 1.328035] i8042: [3] 60 -> i8042 (command)
[ 1.328097] i8042: [3] 74 -> i8042 (parameter)
[ 1.328227] i8042: [3] d3 -> i8042 (command)
Additionally, IRQs are not strictly neccessary and polling may be used.
My WIP patch should definitely check whether the device is sending something.
> BTW your analysis is correct (minus the translations that I could not
> check), so the problem comes later when the psmouse driver tries to probe
> the touchpad.
(In reply to Dmitry Torokhov from comment #104)
> The very first thing we do when probing PS/2 keyboard and/or mouse is issue
> GETID (F2) command. If the device does not respond with data that we
> consider valid keyboard or mouse ID we do not touch that device anymore.
It isn't true:
It may be like in http:// mjg59.dreamwidt h.org/3561. html - some
(In reply to Benjamin Tissoires from comment #103)
> (In reply to Mateusz Jończyk from comment #102)
> What I read in case the touchpad is not working is that no one is trying to
> read from it. The irq might not be even requested, so no one can get events
> from it. It might be a command missing, but to me the problem lies after the
> i8042 controller has been initilized.
>
The IRQ is delivered and this is confirmed when the laptop does not work.
[ 1.327225] i8042: [2] 20 -> i8042 (command)
[ 1.327448] i8042: [2] 54 <- i8042 (return)
[ 1.327471] i8042: [2] 60 -> i8042 (command)
[ 1.327530] i8042: [2] 56 -> i8042 (parameter)
[ 1.327644] i8042: [2] d3 -> i8042 (command)
[ 1.327757] i8042: [2] a5 -> i8042 (parameter)
[ 1.327995] i8042: [3] a5 <- i8042 (aux_test_irq, aux)
[ 1.328035] i8042: [3] 60 -> i8042 (command)
[ 1.328097] i8042: [3] 74 -> i8042 (parameter)
[ 1.328227] i8042: [3] d3 -> i8042 (command)
Additionally, IRQs are not strictly neccessary and polling may be used.
My WIP patch should definitely check whether the device is sending something.
> BTW your analysis is correct (minus the translations that I could not
> check), so the problem comes later when the psmouse driver tries to probe
> the touchpad.
(In reply to Dmitry Torokhov from comment #104)
> The very first thing we do when probing PS/2 keyboard and/or mouse is issue
> GETID (F2) command. If the device does not respond with data that we
> consider valid keyboard or mouse ID we do not touch that device anymore.
It isn't true:
d4 -> i8042 (command)
f2 -> i8042 (parameter) //probe
ab <- i8042 (interrupt, 0, 1)
83 <- i8042 (interrupt, 0, 1)
d4 -> i8042 (command) //???
ed -> i8042 (parameter)
60 -> i8042 (command)
45 -> i8042 (parameter)
60 -> i8042 (command)
47 -> i8042 (parameter)
d4 -> i8042 (command) //reset
ff -> i8042 (parameter)
60 -> i8042 (command)
45 -> i8042 (parameter)
60 -> i8042 (command)
47 -> i8042 (parameter)
f2 -> i8042 (kbd-data)