Bug 386091 - Alt-key gets stuck in vnc server.
Alt-key gets stuck in vnc server.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
8
i386 Linux
low Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
:
: 428076 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-15 20:13 EST by Johnny Stenback
Modified: 2009-11-03 08:55 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 02:26:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log file of session where Alt key gets stuck. (4.95 KB, text/plain)
2007-11-26 19:08 EST, Johnny Stenback
no flags Details
Same as above, but showing what happened past Alt got stuck too. (6.48 KB, text/plain)
2007-11-26 19:16 EST, Johnny Stenback
no flags Details

  None (edit)
Description Johnny Stenback 2007-11-15 20:13:56 EST
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.
Comment 1 Johnny Stenback 2007-11-15 20:19:11 EST
And there it just happened again, within maybe 2 minutes of restarting my vnc
server!
Comment 2 Johnny Stenback 2007-11-15 20:54:05 EST
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.
Comment 3 Adam Tkac 2007-11-19 08:03:57 EST
If I understand correctly you're using TightVNC viewer. Could you please try use
vncviewer from Fedora? It should work as expected.
Comment 4 Johnny Stenback 2007-11-21 17:33:49 EST
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.
Comment 5 Johnny Stenback 2007-11-26 19:07:09 EST
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...
Comment 6 Johnny Stenback 2007-11-26 19:08:26 EST
Created attachment 269401 [details]
Log file of session where Alt key gets stuck.
Comment 7 Johnny Stenback 2007-11-26 19:16:12 EST
Created attachment 269411 [details]
Same as above, but showing what happened past Alt got stuck too.
Comment 8 Johnny Stenback 2007-12-09 04:06:19 EST
Anyone have any thoughts on what's going on here yet? Or pointers as to where in
the code things might be going wrong?
Comment 9 Adam Tkac 2007-12-21 03:10:17 EST
It's, interesting problem. F8 vnc doesn't have any patch related this problem so
I'm not sure what's going on yet.
Comment 10 Johnny Stenback 2007-12-21 03:43:01 EST
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.
Comment 11 Johnny Stenback 2007-12-21 03:43:43 EST
Oh, and FWIW, I see this on x86_64 as well, not only on 32-bit x86.
Comment 12 denis ivanov 2008-01-28 06:10:32 EST
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,
Comment 13 denis ivanov 2008-01-30 17:32:33 EST
*** Bug 428076 has been marked as a duplicate of this bug. ***
Comment 14 Adam Tkac 2008-03-12 14:13:38 EDT
(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?
Comment 15 denis ivanov 2008-03-12 15:33:20 EDT
100% no vnc/vnc libraries at my computer.
Comment 16 Adam Tkac 2008-03-13 08:47:18 EDT
(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.
Comment 17 Bug Zapper 2008-11-26 03:28:54 EST
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
Comment 18 Bug Zapper 2009-01-09 02:26:00 EST
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.

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