Bug 574666 - some keys stop working after several suspend-to-RAM--resume cycles
Summary: some keys stop working after several suspend-to-RAM--resume cycles
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 12
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-18 06:44 UTC by Serguei Miridonov
Modified: 2018-04-11 10:33 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-03 17:09:08 UTC
Type: ---


Attachments (Terms of Use)
Difference between good and wrong xmodmaps (9.55 KB, text/plain)
2010-03-18 06:44 UTC, Serguei Miridonov
no flags Details
xkbcomp output and Xorg.0.log files (37.14 KB, application/x-gzip)
2010-03-26 06:47 UTC, Serguei Miridonov
no flags Details

Description Serguei Miridonov 2010-03-18 06:44:35 UTC
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.

Comment 1 Serguei Miridonov 2010-03-18 07:13:08 UTC
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.

Comment 2 Serguei Miridonov 2010-03-22 05:32:05 UTC
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?

Comment 3 Serguei Miridonov 2010-03-22 15:25:50 UTC
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?

Comment 5 Peter Hutterer 2010-03-25 21:54:36 UTC
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).

Comment 6 Serguei Miridonov 2010-03-26 06:47:01 UTC
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

Comment 7 Serguei Miridonov 2010-03-26 06:48:18 UTC
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?

Comment 8 Bug Zapper 2010-11-03 19:20:25 UTC
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

Comment 9 Serguei Miridonov 2010-11-03 20:12:49 UTC
The bug still exists. Fedora 12, with current update.

Comment 10 Bug Zapper 2010-12-03 17:09:08 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.