[Thinlinc-technical] multiple modifiers
Peter Astrand
astrand at cendio.se
Thu Jan 24 14:05:06 CET 2013
Hi! See comments below.
> I'm playing around with (err, 'evaluating') thinlinc 4.0 with a server
> running on Debian Testing and clients on Debian Testing and Windows
> 7. In general things work very well and I'm impressed - good work!
Thanks :)
Btw, which keyboard layout do you have?
> Most commonly I notice the problem when I want to type M-<
> (alt-shift-,) or M-> (alt-shift-.). The 'alt' part is lost, and I end
> up inserting < or > into the relevant buffer.
>
> I'm not able to reliably cause this to happen, though it feels as though
> it is more likely when I hit shift slightly before alt. If I get into
> the broken state (i.e. < or > is being inserted), then keep shift and
> alt held down, nothing changes. Letting go and pressing again can
> usually result in a working system (but my concentration is destroyed).
When I'm testing, the "end-of-buffer" command is executed correctly when I
press Alt, Shift, "<", but if I press Shift, Alt, "<", then a ">" is inserted.
This is repeatable.
> In a similar vein, I believe that I occasionally see stuck modifiers,
> either control or alt.
>
> These problems occur with both the Debian and Windows clients.
>
> Is there any other experience of this phenomenon? It's ruining an
> otherwise wonderful experience.
I haven't seen stuck modifiers in a long time, but when testing this particular
case, I also got a stuck Alt key. That's ... interesting. Looks like a bug in
our Xserver. I'll continue investigating.
More from your second email:
> The modifier behaviour is stranger than I originally suggested. All
> testing done with the 4.0.0 client on Debian Testing talking to a 4.0.0
> server on the same machine.
>
> Perhaps it's worth mentioning that I'm not running Gnome or KDE - I have
> a simple session that runs the i3 window manager and xterm.
I can also reproduce the problems against eudemo.thinlinc.com, in the GNOME 2
session.
> The Mod1 modifier (the Alt key) is definitely sticking
> regularly. Pressing Alt again clears it. Control is occasionally
> sticky. Pressing Control again clears it. If no chording of the
> modifiers occurs, the stickiness doesn't appear.
Thanks for the investigation. I cannot get Ctrl to stick, though.
> Most odd is the behaviour when I press Mod4-; (that's the Windows key
> and semi-colon). In xev I see:
>
> KeyPress event, serial 29, synthetic NO, window 0x1e00001,
> root 0x105, subw 0xa00013, time 784823137, (302,613), root:(1266,649),
> state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> KeyPress event, serial 29, synthetic NO, window 0x1e00001,
> root 0x105, subw 0xa00013, time 784823241, (302,613), root:(1266,649),
> state 0x40, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> KeyPress event, serial 29, synthetic NO, window 0x1e00001,
> root 0x105, subw 0xa00013, time 784823241, (302,613), root:(1266,649),
> state 0x41, keycode 59 (keysym 0x3b, semicolon), same_screen YES,
> XLookupString gives 1 bytes: (3b) ";"
> XmbLookupString gives 1 bytes: (3b) ";"
> XFilterEvent returns: False
>
> KeyRelease event, serial 29, synthetic NO, window 0x1e00001,
> root 0x105, subw 0xa00013, time 784823241, (302,613), root:(1266,649),
> state 0x41, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
> XLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> KeyRelease event, serial 29, synthetic NO, window 0x1e00001,
> root 0x105, subw 0xa00013, time 784823297, (302,613), root:(1266,649),
> state 0x40, keycode 59 (keysym 0x2c, comma), same_screen YES,
> XLookupString gives 1 bytes: (2c) ","
> XFilterEvent returns: False
>
> KeyRelease event, serial 29, synthetic NO, window 0x1e00001,
> root 0x105, subw 0xa00013, time 784823446, (302,613), root:(1266,649),
> state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
> XLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> There's a spurious KeyPress (and KeyRelease) for the left shift key,
> which I'm definitely not pressing, and the KeyRelease event mentions
> comma (,) rather than semi-colon!
Yes, this looks a little bit strange, but this is actually how it "should" be.
Here's the details: We are using the VNC protocol, which transfers symbolic
"keysyms" rather than physical "keycodes". However, modifier keys also have
keysyms. When you press, the windows key, Super_L is immediately transferred.
Same goes for Shift_L. Then, an actual symbol is produced at the client side:
";", so it is transferred as well. The keyboard state in the remote session has
both Super_L and Shift_L activated. Fortunately, the keyboard layout table has
a way producing ";" in this state. (If not, additional modifiers will be
"faked".) Then, the server will generate keycode 59, and the actual ";" will be
produced. During release, "," will be produced since Shift_L has already been
lifted. This is ok; this is what will happen on a local workstation as well, if
you lift Shift before the symbol key. Applications should not care.
(TLCOS follow up in a separate email.)
Rgds,
---
Peter Astrand ThinLinc Chief Developer
Cendio AB http://cendio.com
Teknikringen 8 http://twitter.com/ThinLinc
583 30 Linkoping http://facebook.com/ThinLinc
Phone: +46-13-214600 http://plus.google.com/112509906846170010689
More information about the Thinlinc-technical
mailing list