Modifier key stuck in a "pressed" state

[Marc Legendre]

Hi there,

I am struggling with an issue where a modifier key can become stuck in
a "pressed" state in the server, and be hard to un-stuck. This can happen for
example if a VNC client fails to send some key up events (e.g. if it loses
focus), or if multiple users try to interact with the same session.

I managed to isolate a case with a specific key combination involving
**shift**.

Precisely, the following sequence of input events will put the server into
a state where the alt modifier is active (not sure if I'm phrasing this
correctly), and simply pressing an alt key (client-side) won't help:

* 65505 down  -- ShiftLeft
* 65513 down  -- AltLeft
* 65505 up    -- ShiftLeft
* 65513 down  -- AltLeft
* 65513 up    -- AltLeft


Furthermore, I noticed that:

* if a VNC client sends only a "65505 down" event, the server reacts by generating a "key 50 pressed" event
* if a VNC client sends only a "65513 down" event, the server reacts by generating a "key 64 pressed" event
* if a VNC client sends a "65505 down" event, then a "65513 down" event, the server reacts by generating a "key 50 pressed" event, then a "key *125* pressed" event

Which I believe is consistent with this bit of configuration described by xmodmap:

```
$ xmodmap -pke | grep Alt_L
keycode  64 = Alt_L Meta_L Alt_L Meta_L
keycode 125 = NoSymbol Alt_L NoSymbol Alt_L
```

Upon further inspection with xev and XQueryKeymap(), here are some more details of what happens when the sequence described aboved is sent :

| VNC event  | X event (xev) | resulting modifier state (xev) | keys pressed, according to XQueryKeymap() |
| ---------- | ------------- | ------------------------------ | ----------- |
| 65505 down | key 50 down   | 0x1                            | 50          |
| 65513 down | key 125 down  | 0x9                            | 50, 125     |
| 65505 up   | key 50 up     | 0x8                            | 125         |
| 65513 down | key 64 down   | 0x8                            | 64, 125     |
| 65513 up   | key 64 up     | 0x8                            | 125         |
| 65513 up   | nothing       | 0x8                            | 125         |

From there, key 125 is still pressed, and thus alt is stuck enabled. (It can be unblocked with "shift+alt", but of course this is not intuitive).

* What would be the proper way to fix/avoid this ? Could it be just a configuration fix? Any hint?

* Also, is there a trick I could use or abuse to workaround this kind of issue? (Like, a trick to "up" all the keys?)

* Am I completely off track?

Any help/hint will be appreciated, I am discovering quite a lot of things here.

--
Marc Legendre

AnatoScope

[DRC]

Thanks for the report.  I will investigate.

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/3161d02e-d10c-443d-a1e7-e9206349c5b8%40googlegroups.com.

[DRC]

I borrowed a patch from TigerVNC that should fix this.  Please re-test with the 2.2.x pre-release build:

https://turbovnc.org/DeveloperInfo/PreReleases

DRC

On 1/10/20 10:01 AM, Marc Legendre wrote:

[Marc Legendre]

On Thursday, January 16, 2020 at 7:13:15 AM UTC+1, DRC wrote:

Please re-test with the 2.2.x pre-release build

 Looks good ! I tested version `2.2.4-20200116`, there's no more "dummy" key 125 pressed, and everything still works as intended as far as I can tell.

--

Marc

[DRC]

Awesome!  Thanks.