[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 fixing. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |