Hi Leann, et al,
        it so happens that my laptop has spent the time since Oct working as a 
replacement for a broken desktop machine.  It is now running Jaunty for me to 
play on and I can confirm that the same suspend problems exist.  I didn't know 
how to continue reporting this bug, should I start a new report for the new 
version, etc.  Your, gratefully received post, makes me think it's all right to 
continue here.

        I guess it's a good idea to start with the basics again, in case
they are useful confirmation, so I have attached “uname -a >
uname-a.log”, “cat /proc/version_signature > version.log”, dmesg >
dmesg.log”, and  “sudo lspci -vvnn > lspci-vvnn.log”.

        Now I can tell you how I got on with the various kernel options
you suggested.  You didn't ask for them, but I am including dmesg.log
files for each option that was collected after the resume, unless
otherwise stated.

        With i8042.direct  - on resume from a sleep, the terminal I have
primed to run dmesm > demesg-i8042-sleep.log come back repeating a comma
keystroke, though hitting return stopped this and allowed me to scroll
back to my primed command.  The trackpad still doesn't work.

        I also still have the same issue with some of the keys sending
the wrong characters.  I now realise that all of these keys with
problems are restricted to the 'NumberPad' cluster on the laptop
keyboard.  It's probably long winded, but for the sake of completeness,
I'll try to explain exactly what goes on.  First a representation on my
numberpad keys – 'Normal key' / 'Numberpad key':-

7 / 7   8 / 8   9 / 9   0 / /
U / 4    I / 5          O / 6   P / *
J / 1   K / 2   L / 3   ; / -
M / 0   < /,            . / .   / / +


.  When the laptop resumes the NmLk led is lit, but keys '7', '8' ,'9', 'u', 
'i', 'o' ,'j', 'k', 'l', 'm' and '.' give no response when tapped, the 
remaining keys '0', 'p', '-', and '/' do yeald the correct numberpad 
characters.  When I use the shift key in combination with keys '7' to 'L' 
above, the correct numberpad response is seen, with the exception of  'm' which 
seems to be giving up details from some paste buffer and actually sends 
'http://start.ubuntu.com/8.10/' to the command line (even though this is 9.04). 
 This buffer is not the same as the 'Ctr-v' buffer, which seems to be empty. 
When I hit a numberpad key in combination with the Fn key I get the expected 
alpha character.

        When I unset the NmLk led, which I have to do by hitting 'Fn
NmLk' twice to take effect, full keyboard use seems to be regained, and
resetting NmLk all numberlock function appear to work as expected.  I am
not quite sure what I should expect from a normal Caps Shifted
numberlock, but the out put does seem to be a bit random :-

7 / H   8 / nr          9 / nr          / / /
4 /nr   5 / nr  6 / nr          * / *
1 / F   2 / nr          3 / nr          - /-
0 / 2~          , / <   . / 2~          + / +

        With i8042.dumbkbd – this time, on resume, the repeated key is
'~'.  Still no trackpad, and the keyboard has the same problem as above,
though I don't seem to be able to affect the same fix – the keyboard
LEDs no longer toggle and I can't seem to clear the numlock state.

        With i8042.noaux – I have no trackpad use to begin with, which
presents me with a problem because I cannot select the sleep action from
the desktop as I have done previously.  Because I had a terminal primed
to go I was able to enter 'sudo /etc/acpi/sleep.sh'.  On resume there
was no repeated keyboard character, though there was some output which
I've copied to noaux.sleep.log.

        i8042.nokbd – Well, no keyboard and no trackpad, so I can't even
log in locally.  Thanks to an ssh login I was able to capture dmesg
before I ran 'sudo /etc/acpi/sleep.sh', but I was unable to re-instate
an ssh session once the laptop resumed.

        i8042.noloop – Ah, well, this seems promising, I now have
trackpad and the keyboard seems to be working as expected.

        i8042.nomux – I have trackpad and keyboard here.

        i8042.nopnp – No trackpad and faulty keyboard as in i8042.direct
and i8042.dumbkbd.

        i8042.reset – Working trackpad and keyboard.

        i8042.reset – Working trackpad and keyboard.

        By default – With no added kernel options, resuming from a
sleep, appears to be like when I tried the .dumbkbd option, repeating
'~' at resume, no trackpad, and the same misbehaving keyboard.


** Attachment added: "uname-a.log"
   http://launchpadlibrarian.net/21877263/uname-a.log

-- 
Keyboard mapping is wrong and no trackpad after suspend on Lenovo N100 0768-6VG
https://bugs.launchpad.net/bugs/287624
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to