Hi, This proposal aims to add support for VNC LED state extension to Qemu VNC server. It also contains the proposal of this VNC extension, althrough it should be sent to some other mailing, but we'd like to send to Qemu mailing list first to have your suggestion. Please let me know your ideas and thoughts.
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. To solve this, we plan to: 1) Add LED state extension to VNC proposal (As the description in 'Proposal for adding LED state extensions to VNC protocol'). 2) Support VNC LED state extension in Qemu. The general flow is: 1) A client that supports the LED state extension starts by requesting the led flags Psuedo-encoding. 2) Server then send a message to the client with the current LED state if this extension is supported. 3) Clinet receive this message and sync with server by setting the local LED state. 4) Everytime the LED state is changed, server will send an update of the current LED state to client, and client will resync with server. For instance, if the change of LED state is requested from remote client through VNC, client will send scancode to VNC server (This is base on the extension 'QEMU Extended Key Event Message' Anthony have already added to VNC protocol as reference link below), server pass the scancode to OS/X11 and then OS/X11 handle the setting of keyboard LED. After the setting job, server receive the LED state event from OS/X11, will send current LED state message to client. Then, client will resync the LED state with server based on this message by setting the local LED state. http://tigervnc.svn.sourceforge.net/viewvc/tigervnc/rfbproto/rfbproto.rst?content-type=text/plain ------ Proposal for adding LED state extensions to VNC protocol QEMU LED state extension Psuedo-encoding ---------------------------------------- A client that supports the LED extension starts by requesting the led flags pseudo-encoding declaring that it is capable of accepting the `QEMU LED state extensions Server Message`_. The server, in turn, will send the current led flags in an update `FrameBufferUpdate`_ with the matching psuedo-encoding and the *num-rectangles* field set to 1, however, no rectangles will actually be sent. After sending this notification, server will update the led flags everytime the led state is changed in the update, client could resync the led state with the server by setting the local led state accordingly. =========================== =================== ======================= No. of bytes Type Description =========================== =================== ======================= 1 ``U8`` *led-flags* =========================== =================== ======================= The example psuedo-encodings for *led-flags* defined as following: ======= =============================================================== Code Description ======= =============================================================== 100 CapsLock is set 010 NumLock is set 001 ScrollLock is set 110 CapsLock and NumLock are set 111 CapsLock, NumLock and ScrollLock are set ======= =============================================================== QEMU LED state extensions Server Message ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This submessage allows the server to send the current led state for the lock keys (CapsLock, NumLock and ScrollLock) to client. =============== ==================== ========== ======================= No. of bytes Type [Value] Description =============== ==================== ========== ======================= 1 ``U8`` 255 *message-type* 1 ``U8`` 2 *submessage-type* 1 ``U8`` *led-flags* =============== ==================== ========== ======================= The *led-flags* fields take the same values as described for the 'QEMU LEDs state extension Psuedo-encoding'_.
