qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] VNC LED state buggy, interop issue


From: Pierre Ossman
Subject: [Qemu-devel] VNC LED state buggy, interop issue
Date: Sat, 10 Dec 2016 16:30:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

Hi,

I'm working on adding support for the LED state extension in TigerVNC. Unfortunately I discovered some bugs in the QEMU implementation so I need to discuss with you guys what the proper behaviour should be.

The basic problem is that the code right now assumes that XK_Caps_Lock and XK_Num_Lock will toggle their respective states. It is however not assumed that XK_Scroll_Lock toggles any state.

This assumption can of course be wrong. Simply run this in your guest to break things:

  xmodmap -e 'clear mod2'

Pressing NumLock will now toggle the LED and state on the client side (that's what is assumed), but not on the server side. However the client is never informed by the server that things are out of sync.

There are two ways to fix this:

a) Send an update to the client when the assumption doesn't hold. This will most likely be difficult in your case since there is no definite point where you can assume a LED change event should have occurred.

 b) Remove the assumption from the code and the protocol.

My vote is for b). Assumptions and side effects are rarely a good idea. The downside though is that it will break compatibility with older versions of QEMU.

Regards
--
Pierre Ossman           Software Development
Cendio AB               http://cendio.com
Teknikringen 8          http://twitter.com/ThinLinc
583 30 Linköping        http://facebook.com/ThinLinc
Phone: +46-13-214600    http://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]