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

[Peter Maydell <peter.maydell@xxxxxxxxxx>]

On 17 September 2014 00:04, Markus Armbruster <armbru@xxxxxxxxxx> wrote:
> Anthony Liguori <anthony@xxxxxxxxxxxxx> writes:
>> 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.

The question of course is what "repeat events" actually means,
both to the VNC protocol and for the semantics of QEMU's internal
input API functions. It looks like the original RBD protocol
docs fail to state how key repeat should be handled.
Googling found somebody's improved version of the protocol docs
https://github.com/sibson/vncdotool/blob/master/docs/rfbproto.rst#keyevent
which says that key repeat should be handled by the client sending
"down down down down down down up" (which is what TigerVNC is
reported to do here). Obviously any clients which take the other
choice and send "down up down up down up" will generally seem
to work pretty much OK because the only distinction is if the guest
looks at the precise difference between keys being held down or
not. So I think our VNC server implementation should also follow
the "down down down up" interpretation of the spec.

Which brings us to the other half of this: what does our
UI layer specify should be the behaviour for key repeat?
Gerd, can you clarify what the common input layer's expectation
is here? Should UI front ends call qemu_input_event_send_key()
with 'down/down/down/up' or 'down/up/down/up' semantics?
(Obviously if you're a UI front end then you're going to have
to convert if your host OS's windowing system has the opposite
set of semantics or some other way of indicating held-down-repeat
like X11's "if the timestamp on "up" and "down" is identical
this is key-repeat. And keyboard-hardware device models
may need to convert again if the semantics of the h/w they're
modelling don't match the common input layer.)

thanks
-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel