On 04/15/13 16:41, Anthony Liguori wrote:
> Gerd Hoffmann <kra...@redhat.com> writes:
>
>> Hi,
>>
>>> When access a guest by console through VNC, there might be
>>> mismatch between the lock keys notification LED on the computer
>>> running the VNC client session and the current status of the lock
>>> keys on the guest machine. This happens because the VNC protocol
>>> does not have any support to deal with setting led state.
>>
>> What is the exact issue you are trying to fix here?
>>
>> The vnc server code in qemu already tracks the keyboard led state and
>> will insert synthetic key events if needed to make sure vnc client and
>> guest machine stay in sync.
>
> If the guest changes LED state, we want to the client to update the
> physical keyboard LED state.
Guests usually change the LED state in response to a keyboard event, in
which case the physical keyboard LEDs already have the correct state.
There are exceptions of course. Guest linux kernel panic-ing, then
blinking capslock. Multiple vnc clients connected at the same time.
> Think thin client without an X server.
Should be even less an issue there.
With X & multiple windows guest+host capslock/numlock state go out of
sync because of sequences like move-kbd-focus-away-from-vncclient-window
+ press-{caps,num}lock + move-focus-back (and thats why we have the
logic to insert synthetic key events to resync in the first place).
What is your vnc client? Does it support VNC_ENCODING_EXT_KEY_EVENT?
cheers,
Gerd
