Description of problem: I run a vnc session on a Fedora 8 box, and I VNC into it all day at work. It's my primary system where I do most of my work. Since I've installed Fedora 8, the Alt key keeps getting stuck in the vnc server, and sometimes there's no way to force it to get unstuck. This seems to happen randomly, sometimes I can use the session for hours w/o problems, other times it gets stuck within just a few minutes of use. My vnc client (TightVNC) has a menu option to send Alt Up, but that does nothing in this case when the Alt key is stuck. Sometimes I'm able to release the Alt key by repeatedly hitting the Alt keys and random keys around it on the keyboard, but other times I might spend several minutes doing that, sending Alt Up through the client, reconnecting, connecting from other hosts, but nothing gets it unstuck and I'm forced to kill the vnc server and start over. Version-Release number of selected component (if applicable): vnc-server-4.1.2-23.fc8 How reproducible: I've seen this several times a day since I installed Fedora 8. Steps to Reproduce: 1. start a vnc server on a Fedora 8 box 2. Use it, sometimes for quite some time, using emacs might help as you'll be using the Alt key frequently. Actual results: Alt key gets stuck eventually, and you can't type etc. Expected results: Alt key shouldn't get stuck.
And there it just happened again, within maybe 2 minutes of restarting my vnc server!
And again... Oh, and I forgot to mention I've been using this same setup on the same hardware for years, running an old Fedora 4 install, with the latest version of vncserver available through the update channels for Fedora 4, and I've had this problem maybe 2 or 3 times in those years, but nothing like now when it's happening several times a day.
If I understand correctly you're using TightVNC viewer. Could you please try use vncviewer from Fedora? It should work as expected.
Yes, I'm using TightVNC, but I'm unfortunately not in a position to test this using vncviewer very easily. And honestly, I don't think this is a problem with the client as I've used this same exact client for years now, and never had this kind of a problem until the upgrade to FC8. I did turn on debug logging for the vnc server, and here's the odd thing I see when I run into this: Wed Nov 21 12:46:01 2007 XserverDesktop: keycode 27 up XserverDesktop: keycode 57 down XserverDesktop: keycode 57 up XserverDesktop: keycode 65 down XserverDesktop: keycode 65 up XserverDesktop: keycode 64 down <--- XserverDesktop: keycode 22 down Wed Nov 21 12:46:02 2007 XserverDesktop: keycode 22 up XserverDesktop: keycode 64 up <--- XserverDesktop: keycode 22 down XserverDesktop: keycode 22 up ... Wed Nov 21 12:46:05 2007 XserverDesktop: keycode 40 down XserverDesktop: keycode 40 up XserverDesktop: keycode 40 down XserverDesktop: keycode 40 up XserverDesktop: keycode 64 up <--- Seems like things are working fine, I get consistent and matching down/up events for the Alt key, the all of a sudden the Alt key gets stuck. When that happens I usually start hitting Alt a bunch of times, and other random keys around it, and sometimes it lets go, but if it doesn't within seconds it seems like it never does. And then from looking at the logs I see the above, I see Alt down/up events from me franticly hitting Alt, and all of a sudden I get an out of sequence Alt up in the logs (pointed out above). This however doesn't release the stuck Alt key. I've stared at the logs and there's no matching Alt down for that out of place Alt up event, and grepping the logs for "keycode 64 up" and "... down" shows that there's one more up events than there are down events. Right now I'm running with the vnc server RPM that shipped with FC7, to see if I'm seeing the same problem there. Let me know if there's anything else I could do here that could help track this down.
Ok, I've now verified that this is not a vnc client problem, or at least it's not a TightVNC problem, I can reproduce this using the vncviewer that ships with FC8. I've got some more data on what's going on here... I can now fairly reliably reproduce this bug. If I start a vnc server, log into it, fire up emacs and type a few lines of text, and then hit Alt+Ctrl+'<', e.g. hold down Alt, Ctrl, Shift, and hit the ',' key (standard US keyboard), that is enough to reproduce this bug. Sometimes it takes 3 or 4 tries, but other times it happens the first time I try. I've got logs (including debug info) of me connecting to a fresh vnc session, launching emacs (by clicking a launcher), and then hitting Alt+Ctrl+'<' followed by Ctrl+'s' (which I one way to tell whether Alt is stuck or not), and that shows in the logs that the vnc server never processed the Alt *down* event (yet emacs saw it), and that appears to be when the Alt key gets stuck. Here's all the keycode log entries from that session: Mon Nov 26 15:50:41 2007 XserverDesktop: keycode 62 down XserverDesktop: keycode 125 down Mon Nov 26 15:50:42 2007 XserverDesktop: keycode 59 down XserverDesktop: keycode 59 up XserverDesktop: keycode 62 up Mon Nov 26 15:50:43 2007 XserverDesktop: keycode 64 up <---- Alt up, but no matching Alt down above! Mon Nov 26 15:50:44 2007 XserverDesktop: keycode 37 down XserverDesktop: keycode 39 down XserverDesktop: keycode 39 up XserverDesktop: keycode 37 up And no, I'm not holding the Alt key down when I connect or anything. Interestingly enough, if I connect with TightVNC and I do the above, Alt gets stuck, but if I hit Alt again, it gets unstuck, and I can repeate the above and get it stuck again, and usually unstuck again too. But if I connect with the vncviewer that shipped with FC8, I have yet to ever manage to get Alt unstuck after it gets stuck in the first place. I'll attach the complete log showing the above. More logs available on request...
Created attachment 269401 [details] Log file of session where Alt key gets stuck.
Created attachment 269411 [details] Same as above, but showing what happened past Alt got stuck too.
Anyone have any thoughts on what's going on here yet? Or pointers as to where in the code things might be going wrong?
It's, interesting problem. F8 vnc doesn't have any patch related this problem so I'm not sure what's going on yet.
FWIW, I ran with the vnc server that shipped with FC 7 (IIRC) for a while too, but font issues aside there was no difference. I.e. I still saw the stuck Alt key with that version as well.
Oh, and FWIW, I see this on x86_64 as well, not only on 32-bit x86.
The same problem on current fedora-devel after run of vmware-player and switching input from/to virtual machine few times. As result, the Alt key work ok but Ctrl and Shift stucked! xorg-x11-server-Xorg-1.4.99.1-0.18.20080107.fc9.i386 xorg-x11-drv-i810-2.2.0-3.fc9.i386 kernel-2.6.24-2.fc9.i686 xorg.conf generated by X automatically (really the problem exists in all versions fc7, fc8 and current fedora-devel) Also please see bug #428076 (Comment #16-2) Seems the same problem also happens when switching between virtual workspaces! I tried run xev and press Escape, Shift-Escape, Ctrl-Escape and Alt-Escape. When all ok: $ xev|grep Escape state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES, state 0x1, keycode 9 (keysym 0xff1b, Escape), same_screen YES, state 0x4, keycode 9 (keysym 0xff1b, Escape), same_screen YES, state 0x8, keycode 9 (keysym 0xff1b, Escape), same_screen YES, When Ctrl and Shift is stucked: state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES, >>> state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES, >>> state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES, state 0x8, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
*** Bug 428076 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > The same problem on current fedora-devel after run of vmware-player and > switching input from/to virtual machine few times. As result, the Alt key work > ok but Ctrl and Shift stucked! > If I understand correctly you have also problems with standalone Xorg without libvnc.so module?
100% no vnc/vnc libraries at my computer.
(In reply to comment #15) > 100% no vnc/vnc libraries at my computer. This information brings quite more light on this problem. If X server without vnc hacks is affected it is main X tree bug. Especially with information from comment #5 I expect bug in keyboard driver. Reassigning to X ninjas for inspection.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 '8'. 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 8'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 8 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
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.