On Di, 2016-12-13 at 14:10 +0100, Pierre Ossman wrote:
> On 13/12/16 09:06, Gerd Hoffmann wrote:
> >> b) Remove the assumption from the code and the protocol.
> >
> > Patches are welcome.
> >
>
> I was just aiming for a consensus on the intended behaviour, rather than
> fix the bug right now. :
On 13/12/16 14:15, Daniel P. Berrange wrote:
gtk-vnc implements the LED state extension.
For testing, I've now pushed my work to get TigerVNC to support this:
https://github.com/CendioOssman/tigervnc/tree/ledstate
It's implemented for the client and Xvnc.
Regards
--
Pierre Ossman
On 13/12/16 14:15, Daniel P. Berrange wrote:
Btw, is there any client that implements this extension yet? I couldn't find
anything.
gtk-vnc implements the LED state extension.
Not enough to actually do anything useful AFAICT. That would be up to
the application using gtk-vnc. And I couldn'
On Tue, Dec 13, 2016 at 02:10:04PM +0100, Pierre Ossman wrote:
> On 13/12/16 09:06, Gerd Hoffmann wrote:
> > > b) Remove the assumption from the code and the protocol.
> >
> > Patches are welcome.
> >
>
> I was just aiming for a consensus on the intended behaviour, rather than fix
> the bug ri
On 13/12/16 09:06, Gerd Hoffmann wrote:
b) Remove the assumption from the code and the protocol.
Patches are welcome.
I was just aiming for a consensus on the intended behaviour, rather than
fix the bug right now. :)
But all right, attached patch is an attempt.
Btw, is there any client
Hi,
> 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.
The whole thing is more intended to make sure guest and host have the
same idea about numlock
On 10/12/16 16:30, Pierre Ossman wrote:
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 t
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
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
