Red Hat Bugzilla – Bug 251777
gnome-settings-daemon & vnc & emacs cause permanent <control> key
Last modified: 2008-06-16 22:08:32 EDT
Description of problem:
This bug occurs when running a fully updated Fedora 7, with the GNOME desktop,
vnc, and emacs. When certain emacs "chords" are used, the <control> key appears
to be always pressed. <control> <left mouse key> now acts like <left mouse key>.
Each key results in the action usually expected for "<control> key". But,
"<control> key" doesn't result in the action for "key".
To isolate the GNOME component causing the problem, I installed "fluxbox". With
that window manager (but gnome-settings-daemon NOT running), the bug does not
occur. But, after running "gnome-control-center" which starts the
gnome-settings-daemon, using emacs for a while causes the bug to occur. The only
way to get out of the session is to do a "vncserver -kill" and restart the VNC
It looks like the key handling of "gnome-settings-daemon" interferes with the
VNC key handling such that a state is reached with no way out.
This could be related to bugs #24460 and #188169.
Version-Release number of selected component (if applicable):
vnc-4.1.2-18.fc7 (for client), or Windows "tightvnc" client, or Windows
Always, but need to use emacs a few minutes with different key chords including
Steps to Reproduce:
1. Start VNC server on a computer DIFFERENT from the computer the vnc viewer is
2. Start VNC viewer. Play with emacs. Everything should be OK.
3. Run "gnome-control-center" to start the "gnome-settings-daemon". Play with
emacs, use chords.
4. Hit "<control>g" every once in a while. At some point, it is displayed as
<Alt><control>g or a chord different from "<control>g".
vnc server has to be restarted from a different terminal.
Should be able to use GNOME, VNC, and emacs with no problem. This issue has
never occurred to the best of my knowledge.
Under the same conditions, I see another probably related bug. When using
OpenOffice or Thunderbird and typing text, every once in a while a keystroke
initiates an endless loop of typing the same key over and over. I haven't
checked whether this behavior occurs with "fluxbox" and no gnome-settings-daemon.
The related bug is 244600, not 24460.
Also, in step 3., after starting "gnome-control-center", I changed the GNOME
font. I don't know for sure whether this is needed to start the daemon or not.
if you run gnome-accessibility-keyboard-properties do you have mouse keys enabled?
Created attachment 161328 [details]
First emacs dribble file.
Created attachment 161329 [details]
Second emacs "dribble" file
Created attachment 161330 [details]
Third emacs "dribble" file
The above emacs "dribble" files show the effect of switching in the <meta> key
inadvertently. I found out that this most often happens after
<ctl><alt><shift>^, then the <ctl>g which should terminate the command becomes
<ctl><meta>g. I also found that I can switch back to the normal state with
<ctl><alt><shift>% followed by <ctl>g. Note that in
Preferences->Hardware->Keyboard, under Alt/Win key behavior, I set "<Alt> and
<Meta> are on the <Alt> keys (default)". I don't know whether this is related to
To your question: No, I don't have any gnome-accessibility-keyboard-properties
set, mouse or otherwise.
I am now running Fedora 8 and the bug still exists. I basically can't run GNOME
in VNC and use Emacs. So, I am now using "fluxbox" in VNC which has no issues -
I am using this combination daily. If I switch to GNOME, the Emacs bug occurs
within a few minutes of use, especially when using "chords" like <ALT><CNTL><SHIFT>%
which is query-replace-regexp.
Does it make sense to replace vncserver with, e.g., tightvnc and see whether
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.
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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 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.