Bug 1086650

Is this happening with RHEL client as well? If yes, please open a duplicate.

I can't reproduce with localhost fedora, and rhel6 guest.
with tc qdisc add dev lo root netem los 20% delay 200ms

Since v0.13-15-g0d5ad7e we have code to deal with press_and_release, to differentiate from sending press and release.

How do you type on keyboard during testing?

If you keep key pressed long (more than 100ms) then it will be considered as a press event, and repeat might trigger on guest.

If you type normally, you are usually under the 100ms, and a single "atomic" press/release event is sent to server/guest.

I can reproduce.



(remote-viewer.exe:940): GSpice-DEBUG: key_event press: keycode: 81  state: 0  g
(remote-viewer.exe:940): GSpice-DEBUG: delayed press 16
(remote-viewer.exe:940): GSpice-DEBUG: key_event press: keycode: 87  state: 0  g
(remote-viewer.exe:940): GSpice-DEBUG: key_event release: keycode: 81  state: 0
(remote-viewer.exe:940): GSpice-DEBUG: delayed press 17
(remote-viewer.exe:940): GSpice-DEBUG: release 16
(remote-viewer.exe:940): GSpice-DEBUG: key_event release: keycode: 87  state: 0
(remote-viewer.exe:940): GSpice-DEBUG: release 17
(remote-viewer.exe:940): GSpice-DEBUG: key_event press: keycode: 69  state: 0  g
(remote-viewer.exe:940): GSpice-DEBUG: key_event release: keycode: 69  state: 0
(remote-viewer.exe:940): GSpice-DEBUG: press and release 18

Typing fast enough make press/release event overlap over keys.

In this case the current filtering code isn't good enough to trigger a single press_and_release() event. The send_key() logic needs to be improved.

though the key is always eventually released. Are you saying that the key is never released, sometime?

I have not seen key being stuck forever, pressing the stuck key again helps release the key faster.

actually, the logic in send_key() is correct, we need to send seperate press and release event when we get such overlapped key sequence.

I am afraid we will have to send longer scancode sequences of arbitrary events, and not individual events,..

I wonder if we shouldn't delay/buffer all keys events until the keyboard is released or a delay of 100ms is triggered (so that we keep event sequence, and send an atomic message to avoid repeatition)

(In reply to Marc-Andre Lureau from comment #5)
> ...
> Typing fast enough make press/release event overlap over keys.
> 
> In this case the current filtering code isn't good enough to trigger a
> single press_and_release() event. The send_key() logic needs to be improved.

(In reply to Marc-Andre Lureau from comment #8)
> actually, the logic in send_key() is correct, we need to send seperate press
> and release event when we get such overlapped key sequence.
> 
> I am afraid we will have to send longer scancode sequences of arbitrary
> events, and not individual events,..

So this isn't a regression of bug 812347?

When you say "overlapped key sequence", does that happen only when deliberately pressing more keys at once (such as when using modifiers with keys) or is just fast-enough one-after-another typing enough to trigger the bug? I suppose it's the latter, just to make sure...

(In reply to David Jaša from comment #10)
> (In reply to Marc-Andre Lureau from comment #5)
> > ...
> > Typing fast enough make press/release event overlap over keys.
> > 
> > In this case the current filtering code isn't good enough to trigger a
> > single press_and_release() event. The send_key() logic needs to be improved.
> 
> (In reply to Marc-Andre Lureau from comment #8)
> > actually, the logic in send_key() is correct, we need to send seperate press
> > and release event when we get such overlapped key sequence.
> > 
> > I am afraid we will have to send longer scancode sequences of arbitrary
> > events, and not individual events,..
> 
> So this isn't a regression of bug 812347?

No, you would have even more key repeatitions. Now key repeatition is only happening when press/release events between different keys are overlapping. In some ways, this was done like this by design not by mistake, thinking that it wouldn't trigger easily, but it seems it is easy to trigger..

> When you say "overlapped key sequence", does that happen only when
> deliberately pressing more keys at once (such as when using modifiers with
> keys) or is just fast-enough one-after-another typing enough to trigger the
> bug? I suppose it's the latter, just to make sure...

Both cases can trigger key repeat events, since press and release events will be sent as seperate events in those cases. 

I think my proposal from comment #9 still holds. Feel free to suggest more ideas...

I've been testing a few ideas to solve the problem but none of them came without drawbacks, unfortunately.
Marc-André's idea about delay/buffer for all key events till the keyboard is released also has drawbacks. Indiscriminately disabling key repeat in the guest is not a good solution as well, as pointed out is this discussion (http://comments.gmane.org/gmane.comp.emulators.spice.devel/8927) about bug 812347, but this is what can be done by the user when using a poor connection.

Pointing out also that VMWare and other remote desktop solutions have recommendations to disable or set guest settings to long delay before the repeat triggers, see for ex this KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=196.

Note that qemu doesn't implement hw/at key repeat, so in linux console by default (without sw repeater), keyrepeats are generated by clients and will not suffer undesired key repeats (kbdrate settings are ignored, only client settings matter).