Hi. I'm debugging a keyboard problem where modifiers, such as shift,
sometimes are stuck. Unfortunately, the problem happens very seldom, which
makes it hard to debug. What's worse is that it seems like we are facing
multiple problems: I believe we have a VNC specific bug, but the fact is
that similar problems are also occuring on "fat" machines, ie there are a
bunch of keyboard and modifier related bugs in Xorg as well (no
news...). I'm referencing Fedora bugs here, as examples:
https://bugzilla.redhat.com/show_bug.cgi?id=481225 (random key-repeats and
shift key causes shift-lock)
https://bugzilla.redhat.com/show_bug.cgi?id=445898 (Slow keys turn on
spontaneously, output two symbols at once)
...both describes similar problem, although in different components. We
also have "my favourite" (most hated) bug:
https://bugzilla.redhat.com/show_bug.cgi?id=494999 (Mouse freezes - moves
but won't click)
We have also occasionally seen "shift lock" problems on Fedora 11 as well
as the Fedora 12 beta workstations...
As I said, however, the particular problem I'm debugging is /probably/ VNC
specific. There are earlier reports of this problem, such as:
https://bugzilla.redhat.com/show_bug.cgi?id=386091 (Alt-key gets stuck in
vnc server.)
I've also been able to reproduce this problem with the vnc-server
package that's shipped in Fedora 10 (RealVNC with X.Org 1.5.3). In some
cases, such as with F10, it's really difficult to trigger the problem.
With our build of TigerVNC, however, it's easier. What I usually do is to
continously press a key such as "a", and at the same time (but more
seldom) also press the shift key. When you start seeing "A" releases and
Shift presses even "in between" the shift presses, you have triggered the
bug: Shift is stuck down. (You can recover by pressing shift once.)
I've also managed to catch a Xvnc log:
XserverDesktop: keycode 38 up
XserverDesktop: keycode 38 down
XserverDesktop: keycode 38 up
XserverDesktop: keycode 38 down
XserverDesktop: keycode 62 down
XserverDesktop: keycode 38 up
XserverDesktop: keycode 62 up
XserverDesktop: fake keycode 62 up
XserverDesktop: keycode 38 down
XserverDesktop: fake keycode 62 down
The "fake keycodes" starts when the bug is triggered. As you can see, Xvnc
is trying to fake a "shift up" even though it just generated such an
event! It then tries to "clean up" before finishing this keyboard even by
(incorrectly) "restoring" the shift down state. The question is of course
why it's trying to do that. If one inspects the code, one can see that
Xvnc is checking if a modifier is active by looking at
vncKeyboardDevice->key->state. Events are generated by calling
mieqEnqueue(). Without knowing the internals of mieqEnqueue(), this looks
suspicious to me. Perhaps the queue isn't processed immediately, so that
vncKeyboardDevice->key->state isn't (yet) updated when Xvnc is about to
create/queue the next event? I think we need some kind of mieqFlush()
operation, or redesign the "fake modifiers" code paths. Or perhaps I have
misunderstood the problem completely...
Best regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
