Created attachment 400958 [details] Difference between good and wrong xmodmaps Description of problem: After several days of up time with 2-3 suspend-to-RAM--resume cycles every day some keys stop working. Version-Release number of selected component (if applicable): kernel-2.6.32.9-70.fc12.i686 xorg-x11-server-Xorg-1.7.5.901-4.fc12.i686 xorg-x11-xkb-utils-7.4-6.fc12.i686 xorg-x11-drv-keyboard-1.4.0-2.fc12.i686 xorg-x11-drv-nvidia-195.36.08-1.fc12.i686 Hardware: HP Pavilion dv5 notebook. More info available here: http://www.smolts.org/client/show/pub_185f33b5-e602-4fae-8714-fbc22a26e63f How reproducible: 100% after 3-4 days of up time. Steps to Reproduce: 1. Use the notebook 3-5 days. 2. Don't reboot or restart X server. Just suspend-to-RAM and resume 2-3 times per day. 3. Check Up, Down, PageUp/Down, Insert, Delete keys if they work as expected. Actual results: Up, Down, PageUp/Down, Insert, Delete keys stop working. Expected results: Keys work as expected. Additional info: xev and xmodmap -pke show wrong mapping for keys mentioned above. Using "Switch User"->"New xsession" a new X server can be started where keys work normally. With 'xmodmap -pke > /tmp/xmodmap.default' in this session it is possible to save normal keyboard map and then load it in the session with wrong mapping. After that the problem can be partially fixed. Keys start to work normally but pressing and holding "Left" or "Down" keys still produces wrong sequence, while simple press-release these keys works as expected. Still something is wrong with key repeat... Difference file from 'xmodmap -pke' for both sessions is attached.
Additional information: Even after running xmodmap for loading good mapping, switching to text-only virtual console and back to X session returns keyboard to wrong mapping.
Today after 3 days, 16:21 of uptime (10 sleep-resume cycles) it happened again. It becomes annoying... Anybody has an idea how to fix it?
OK, I have just found that this has nothing to do with suspend-resume. The same problem with keyboard happens right after 10 switch-to-text-console and back cycles (Ctrl-Alt-F2 and then Alt-F1: repeat 10 times). Is there anything to check in order to find the reason? How can I check keyboard mapping and other keyboard settings by something other than xmodmap?
can you please attach your Xorg.log and the output of "xkbcomp -xkb $DISPLAY -" before and after the change happens. This should give us some indication what's going on. Do you run a desktop environment? If so, does the same issue occur when you're just starting the X server with "xinit --" from runlevel 3? (note, you need to install xterm before doing so).
Created attachment 402757 [details] xkbcomp output and Xorg.0.log files Contents: xkb-files/kde-xkbcomp.output.good xkb-files/kde-xkbcomp.output.wrong xkb-files/kde-Xorg.0.log xkb-files/xinit-xkbcomp.output.good xkb-files/xinit-xkbcomp.output.good-2 xkb-files/xinit-xkbcomp.warning xkb-files/xinit-Xorg.0.log
Thank you for replying. (In reply to comment #5) > can you please attach your Xorg.log and > the output of "xkbcomp -xkb $DISPLAY -" > before and after the change happens. This > should give us some indication what's > going on. Requested files are attached in one xkb-files.tar.gz archive: xkb-files/kde-xkbcomp.output.good xkb-files/kde-xkbcomp.output.wrong xkb-files/kde-Xorg.0.log xkb-files/xinit-xkbcomp.output.good xkb-files/xinit-xkbcomp.output.good-2 xkb-files/xinit-xkbcomp.warning xkb-files/xinit-Xorg.0.log For KDE session: kde-xkbcomp.output.good: contains normal xkb map kde-xkbcomp.output.wrong: after 10 times switching to text console and back kde-Xorg.0.log: taken when keymap becomes wrong. I have found no indication to any problem. > Do you run a desktop environment? Yes, I use KDE which uses setxkbmap -model hpdv5 -layout us,ru -variant ,phonetic to set up keyboard layout, and setxkbmap -option grp:lwin_toggle,grp_led:scroll to use ScrollLock LED for indication of Russian mode. The LED indication does not work though since upgrade to KDE 4.4.x > If so, does the same issue occur when you're > just starting the X server with "xinit --" from runlevel 3? No, it doesn't. Files for xinit initiated X session: xkb-files/xinit-xkbcomp.output.good: first run xkb-files/xinit-xkbcomp.output.good-2: after more than 10 switches to text console and back. No difference. xkb-files/xinit-xkbcomp.warning xkb-files/xinit-Xorg.0.log I have also noticed one thing which could be important for your consideration... I saved good working keymap and use it to fix layout by "xkbcomp GoodMap.xkb $DISPLAY" when it is broken after more than 10 suspend-resume cycles, or after 10 times switching to text console and back to X session. But when the layout appears to be fixed after that, if I open KDE keyboard control module, change something there and click "Apply", the keymap appears to be broken again. The same happens after "setxkbmap" commands shown above. Anything else?
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The bug still exists. Fedora 12, with current update.
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.