Open any1 opened 1 year ago
I've been looking at this more closely, and I've discovered the following:
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:
It appears that the client does not make any attempt at synchonising the state.
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.
The following situations cause lock key state to become desynchronised:
This should be implemented per-client to support multi-seat.
Extensions:
See: https://github.com/any1/wayvnc/issues/271