Latest working kernel version: ? Earliest failing kernel version: ? Distribution: Ubuntu Linux 8.04 Hardware Environment: Dell Vostro 1000 (European for Dell Inspiron 1501 I suppose, having an AMD cpu) Software Environment: everything Problem Description: On *some* *cold* boots, the AltGr key is not working, so when I press AltGr+somekey I get scrambled characters (both on console and X mode). The problem never appears on warm boots (i.e.: after a reboot), and it didn't appear until a couple of months ago (but I cannot remember which kernel version did originate the problem). Also see https://bugs.launchpad.net/ubuntu/+bug/285908. Note: on wrong boots dmesg reports: input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input1 while right boots report: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1 Steps to reproduce: ? You just have to be "lucky" and you will boot up in the wrong state...
Reassigned to drivers/input
2.6.24-16-generic (the first kernel used by Ubuntu 8.04) was working perfectly... the problem generated later, between 2.6.24-17 and 2.6.24-22...
Hi, isn't it possible to revert the changes that originated the problem? thanks, MZ
See ubuntu bug # 258908: the problem *seems* solved by adding "i8042.reset=1" to the GRUB command line (thanks to Daniel's suggestions)... hope this helps, thanks, MZ
See ubuntu bug #258908: I had to use "i8042.reset i8042.nomux i8042.nopnp i8042.noloop" instead of just "i8042.reset", otherwise my keyboard hanged up on cold boots 80% of the times! Hope this helps, thanks, MZ
unfortunately, the keyboard still hangs up most of the times, even with those additional kernel parameters... thanks, MZ
just tested the Ubuntu 9.10 Alpha4 a few weeks ago, the problem is still there... thanks, MZ
This problem also exists in Mandriva, as reported here: https://qa.mandriva.com/show_bug.cgi?id=49873
yes, I read Yves' report and that seems to be the very same annoying problem... thanks, MZ
Hi all, is there any news abou this? if not, is there a way to pass some kernel parameters at boot and "reset" the driver behaviour, so that it is not necessary to make a reboot 50% of the times I switch the computer on? thanks very much, MZ
Provided my problem indeed IS related to this report, then this script works as a workaround in X; run it each time AltGr stops working: --------------------------------------------------- #!/bin/bash # https://bugs.launchpad.net/linux/+bug/285908 xmodmap -pke | sed 's/XF86Launch1/ISO_Level3_Shift/g' >/tmp/xmodmap xmodmap /tmp/xmodmap rm -f /tmp/xmodmap --------------------------------------------------- Yves.
Yves, thanks for pointing me to that Ubuntu bug report (which I opened, BTW :), unfortunately, "xmodmap -pke" for me reports: ... keycode 156 = NoSymbol Meta_L ... so I cannot replace "XF86Launch1"... thanks, MZ
Vojtech Pavlik, the maintainer for the "AT keyboard" Linux driver, told me that a way to force the keyboard in "raw" mode (which is what happens on buggy boots) is to boot with "i8042.direct=1". Unfortunately, there is not the opposite option, i.e.: you cannot force the keyboard in "translated" mode with "i8042.direct=0". That would be useful to circumvent the bug. Apart from this, I attach: - output from the "evtest" keypress for "@" while in buggy (raw) mode; - output from the "evtest" keypress for "@" while in correct (translated) mode; - output from dmesg while in buggy mode and "i8042.debug=1".. Thanks, MZ
Created attachment 25288 [details] evtest output for @ keypress while in raw mode
Created attachment 25289 [details] evtest output for @ keypress while in translated mode
Created attachment 25290 [details] dmesg output for @ keypress while in raw mode
Quick analysis: The Vostro hardware exhibits two bugs here: 1) Unpredictably, sometimes the keyboard controller initializes in Raw mode instead of Translated. The Raw mode works, and provides a working keyboard. However, to provide consistent behavior it'd be better to force Translated mode on this machine, using DMI quirks. 2) When in Raw mode it sends an incorrect scancode for the right alt, it sends 91 HEX (145) instead of 91 DEC, the correct scancode. This could be worked around by updating the scancode table based on a dmi quirk and translated/raw state, but if 1) is worked around, this won't be necessary anymore. Reassigning to input-devices, too.
Bleh, another DMI quirk... I wonder if we should ban raw mode on all x86 laptops and portables. Vojtech, what do you think?
If you can detect an x86/x86-64 laptop, then great. In fact I think we could force translated mode (enable it if not enabled in the CTR) on any x86 or x86-64 system unless the user overrides that with i8042.direct. The current behavior is: If i8042.direct=0, then check the CTR and use the mode the CTR reports if i8042.direct=1, then set CTR to and use Raw mode We could change it (on x86 and x86-64) to: if i8042.direct=0, then set CTR to and use Translated mode if i8042.direct=1, then set CTR to and use Raw mode All the x86 machines that couldn't do Translated are dead by today. Or maybe make the option more flexible, with three values, and different defaults based on architecture.
Ping did this get resolved as I don't see it added to the reset table in 3.4
I’ve been using Arch Linux instead of Mandriva on this laptop for almost 6 months now, hence with newer kernels. Ever since, I’ve never had the bug happen. As far as I’m concerned (on a Dell Inspiron 1501), the bug is solved.
Thanks - good to know
Sorry for the delay in answering, but I needed to test - and I can confirm this bug has gone! Thanks, Marco