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 server. 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): control-center-2.18.0-18.fc7 vnc-server-4.1.2-18.fc7 vnc-4.1.2-18.fc7 (for client), or Windows "tightvnc" client, or Windows "realvnc" client. How reproducible: Always, but need to use emacs a few minutes with different key chords including <Alt><control><Shift> Steps to Reproduce: 1. Start VNC server on a computer DIFFERENT from the computer the vnc viewer is run on. 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". Actual results: vnc server has to be restarted from a different terminal. Expected results: Should be able to use GNOME, VNC, and emacs with no problem. This issue has never occurred to the best of my knowledge. Additional info: 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 the bug.
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 works?
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: http://docs.fedoraproject.org/release-notes/ 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.