Locked keyboard modifier synchronisation

[any1]

The following situations cause lock key state to become desynchronised:

• Client connects while a key is locked
• Client window loses focus, lock key state is changed, window gets focus
• Physical keyboard state on the server is altered
• Another client modifies keyboard state

This should be implemented per-client to support multi-seat.

Extensions:

• https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-led-state-pseudo-encoding
• https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vmware-led-state-pseudo-encoding

See: any1/wayvnc#271

[any1]

I've been looking at this more closely, and I've discovered the following:

• The virtual keyboard does not share LED state with other keyboards
• When you create a new virtual keyboard, its initial LED state is always unset.
• There is no wayland protocol that allows setting the LED state. It can only be set by a keyboard.

Each client has its own virtual keyboard. This means that we don't have to worry about synchonising state between clients and we do not have to worry about getting the right state when we connect.

However, I have noticed, that when connecting with TigerVNC, the following sequence of events causes issues:

• Focus outside VNC client and press CAPS LOCK
• Focus VNC client, and type. The text will not be upper case.

It appears that the client does not make any attempt at synchonising the state.

[any1]

Since LED state cannot change on the server side and it's reset when the client disconnects, and it's not shared between clients, a client that's connecting to WayVNC can reliably track the state without the server's help. However, it seems that VNC clients won't do this. They depend on the qemu/vmware extensions.

To pacify those clients, LED state extensions need to be implemented, but since the VNC client can't update the local LED state, it must fight the server instead. I.e. whenever the server sends a new state, the client needs to toggle modifiers to achieve its own desired state. This is bound to race and/or cause contention if done immediately upon receiving a LED state event from the server.

It seems that the only reasonable solution is to force the LED state upon the server right before any keyboard event. This can still race, but causes less contention.

I've implemented the LED state extensions, and now TigerVNC will actually sync the state, but only after focusing the window again for a second time.