[Thinlinc-technical] multiple modifiers

[Peter Astrand]

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