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

Re: [Xen-devel] [Qemu-devel] [PATCH] vnc: add additional key up event before repeated key down

Anthony Liguori <anthony@xxxxxxxxxxxxx> writes:

> On Tue, Sep 9, 2014 at 8:31 PM, Chun Yan Liu <cyliu@xxxxxxxx> wrote:
>>>>> On 9/10/2014 at 02:23 AM, in message
>>>>> <87tx4girg6.fsf@xxxxxxxxxxxxxxxxxxxxx>,
>> Markus Armbruster <armbru@xxxxxxxxxx> wrote:
>>> "Chun Yan Liu" <cyliu@xxxxxxxx> writes:
>>>>>>> On 9/6/2014 at 05:23 AM, in message
>>> > <alpine.DEB.2.02.1409052202451.2334@xxxxxxxxxxxxxxxxxxxxxxx>, Stefano
>>> > Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>>> >> On Fri, 5 Sep 2014, Chunyan Liu wrote:
>>> >> > Using xen tools 'xl vncviewer' with tigervnc (default on SLE-12),
>>> >> > found that: the display of the guest is unexpected while keep
>>> >> > pressing a key. We expect the same character multiple times, but
>>> >> > it prints only one time. This happens on a PV guest in text mode.
>>> >> >
>>> >> > After debugging, found that tigervnc sends repeated key down events
>>> >> > in this case, to differentiate from user pressing the same key many
>>> >> > times. Vnc server only prints the character when it finally receives
>>> >> > key up event.
>>> >>
>>> >> Is this actually how a vnc client should behave?
>>> >> How do the vnc client and server from realvnc behave in this regard
>>> >> (they are the reference implementation)?
>>> >
>>> > VNC protocol doesn't specify how to handle key repetition. Tightvnc
>>> > sends key-down&key-up repeatedly, but some example like RealVNC for
>>> > Windows does the same thing - it sends only repeated key-down.
>>> >
>>> > Generally the VNC keyboard handling gives lot of space for interpretation
>>> > and so the implementations differ.
>>> If implementations differ, and QEMU already behaves like some of them,
>>> then why change it?
>> To change qemu side because we could not expect each VNC client behaves
>> the same when holding key down, some sending key-down, key-up, key-down,
>> key-up; but some sending key-down, key-down, key-down .... Without change,
>> client only sending key-down, key-up, key-down,key-up ... can get correct
>> display.
> The VNC keyboard handling is pretty straight forward.   The keys sent
> are symbolic and correspond to input events (as interpreted by an
> application).  Whether you get repeat events depends on a lot of
> client side configuration.
>>>  What exactly gets fixed and what gets broken by the
>>> proposed change?
>> Holding the key down, only one character is printed, but repeated characters
>> are expected. Happens on some vnc client. Either vnc client or vnc server
>> should change some to match.
> You should fix TigerVNC.  It's broken if it isn't sending repeat events.

It *is* sending repeat events.  The commit message says so, and I
tested it to confirm.

Key repeat works just fine for me in the guest, both in Grub and in
Linux.  It obviously doesn't for Chunyan Liu "on a PV guest in text
mode."  I suspect that PV guest's handling of key repeat is what needs

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.