qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Support for VNC LED state extension proposal
Date: Mon, 22 Apr 2013 14:32:21 -0500
User-agent: Notmuch/0.15.2+77~g661dcf8 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Gerd Hoffmann <address@hidden> writes:

>   Hi,
>
>>> 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.
>
> Neat.  URL?

We haven't published yet but I keep meaning too...  It's really quite simple.

> Does the linux kernel keep track of {caps,num}lock state (+leds) with
> the keyboard in mediumraw mode?

Nope.

> Or does it expect the userspace app set the led state then?

Yup.

> No UI client (neither vnc nor spice) knows the guest keymap btw.

Well, they do actually.

gtk-vnc has key modifier tracking code.  I assume gtk-spice does too.
This code looks at the GdkEventKey::keysym which has gone through the
host keymap.  The assumption is that the host keymap == the guest keymap
at least as far as modifiers are concerned.

Take a look at key_event in vncdisplay.c in gtk-vnc.

>> 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.
>
> Anyone tried to bug vmware to open the specs for the existing
> extension?

I have in the past but that was many years ago at this point.

Regards,

Anthony Liguori

>
> cheers,
>   Gerd




reply via email to

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