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

[Anthony Liguori <aliguori@us.ibm.com>]

Gerd Hoffmann <kraxel@redhat.com> writes:

> 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.

Ack.

> There are exceptions of course.  Guest linux kernel panic-ing, then
> blinking capslock.  Multiple vnc clients connected at the same time.

Ack.

>> 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?

It's uses gvnc as a protocol library and renders via fbdev.  It reads
keyboard events by putting /dev/tty into mediumraw mode and uses ext key
events exclusively.  It has no knowledge of the guest keymap.

It is possible to attempt to keep the LED state in sync by tracking the
lock key state in the client.  However, there are drawbacks to this.

Since the client isn't aware of the guest keymap, it technically doesn't
know which keys are the lock keys.  Admittedly, this is a solvable
problem but the solution is certainly not elegant.

There's also the problem with guest initiated LED changes that don't
correspond to lock key presses.  Admittedly not a huge problem but still
there nonetheless.

I believe VMware already has a VNC extension for passing LED state
changes and I think having an open extension for this is a Good Thing.
It's a pretty obvious missing piece in the VNC protocol.

Regards,

Anthony Liguori

>
> cheers,
>   Gerd