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

[Markus Armbruster <armbru@xxxxxxxxxx>]

Peter Maydell <peter.maydell@xxxxxxxxxx> writes:

> 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.

I agree.

One way to fill the gap in the spec is "the protocol does not allow for
repeating keys, so we need to do the next best thing and pretend the
user hit the key repeatedly".  This dumbs down a repeating keypress to
repeated keypresses.

Another way is "everybody knows how repeating keys work (down, down,
..., down, up), and that's why the the protocol doesn't mention it".

If the sending side dumbs down repeating keypress to repeated
keypresses, the receiving side cannot distinguish one from the other
anymore.  Bad.

If the sending side sends repeating keys, but the receiving side doesn't
understand that, key repeat doesn't work.  Also bad.

Making the receiving side understand has no downside, unlike making the
sending side dumb things down.

> 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.)

PC keyboards send "down, down, ..., down, up".  A quick glance at the
code suggests our device model expects to get exactly that from the
input layer.

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