Re: [Qemu-devel] Support for VNC LED state extension proposal

[Gerd Hoffmann <kraxel@redhat.com>]

On 04/15/13 16:41, Anthony Liguori wrote:
> Gerd Hoffmann <kraxel@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