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):
Hardware: HP Pavilion dv5 notebook. More info available here:
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.
Up, Down, PageUp/Down, Insert, Delete keys stop working.
Keys work as expected.
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
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:
For KDE session:
kde-xkbcomp.output.good: contains normal xkb map
kde-xkbcomp.output.wrong: after 10 times switching to text console and
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.
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.
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:
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.