[Qemu-devel] Key repeat is no longer working on TTY and grub menu

[Qemu-devel] Key repeat is no longer working on TTY and grub menu

[Leonardo Soares Müller]

I noticed that the key inputs are no longer repeating when using default
setting on QEMU. For example, if I press "a" and keep it pressed it will
print only one "a" instead of repeating them. Another example is when
deleting text: instead of holding backspace pressed and the text is
deleted, it's needed to press backspace once for each character.

As this makes many tasks much slower, requiring many key presses for
tasks that were done in a single press, I did a bisect to see when this
change happened. The result is:

0c0d42737dfdcea872a987ecba6ef55047df8881 is the first bad commit
commit 0c0d42737dfdcea872a987ecba6ef55047df8881
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Jan 22 10:28:11 2019 +0100

    kbd-state: use state tracker for gtk

    Use the new keyboard state tracked for gtk.  Allows to drop the
    gtk-specific modifier state tracking code.

    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
    Message-id: 20190122092814.14919-6-kraxel@redhat.com

:040000 040000 e882f144bafca90257a4604b5e62486a1ca038b2
0139afe1aee24256c3f711c080b0230ab104074a M	include
:040000 040000 c258efc06107b944b0627792b9f2377600033118
4fd01a25a3e0d1fccca72c35ec58b205aa4fd882 M	ui

I'm using the GTK interface and all guests without a Graphical User
Interface (GUI) are affected by this. This happens on grub menu and on
TTY of multiple Linux guests.

Workarounds found for the key repeat issue:

-Installing a GUI to server systems;
-Adding a usb-kbd device, but then the key '/' is lost.

Re: [Qemu-devel] Key repeat is no longer working on TTY and grub menu

[Daniel P. Berrangé]

On Tue, Feb 12, 2019 at 01:02:42PM +0000, Leonardo Soares Müller wrote:
> I noticed that the key inputs are no longer repeating when using default
> setting on QEMU. For example, if I press "a" and keep it pressed it will
> print only one "a" instead of repeating them. Another example is when
> deleting text: instead of holding backspace pressed and the text is
> deleted, it's needed to press backspace once for each character.
> 
> As this makes many tasks much slower, requiring many key presses for
> tasks that were done in a single press, I did a bisect to see when this
> change happened. The result is:
> 
> 0c0d42737dfdcea872a987ecba6ef55047df8881 is the first bad commit
> commit 0c0d42737dfdcea872a987ecba6ef55047df8881
> Author: Gerd Hoffmann <kraxel@redhat.com>
> Date:   Tue Jan 22 10:28:11 2019 +0100
> 
>     kbd-state: use state tracker for gtk
> 
>     Use the new keyboard state tracked for gtk.  Allows to drop the
>     gtk-specific modifier state tracking code.
> 
>     Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>     Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>     Message-id: 20190122092814.14919-6-kraxel@redhat.com
> 
> :040000 040000 e882f144bafca90257a4604b5e62486a1ca038b2
> 0139afe1aee24256c3f711c080b0230ab104074a M	include
> :040000 040000 c258efc06107b944b0627792b9f2377600033118
> 4fd01a25a3e0d1fccca72c35ec58b205aa4fd882 M	ui
> 
> I'm using the GTK interface and all guests without a Graphical User
> Interface (GUI) are affected by this. This happens on grub menu and on
> TTY of multiple Linux guests.

Yes, this is another regression accidentally introduced by the keyboard
state tracker.

When GTK does key repeat it omits the Up event for repeated keys.

IOW, you get

    Press (a)
    Press (a)
    Press (a)
    Release (a)

Not

    Press (a)
    Release (a)
    Press (a)
    Release (a)
    Press (a)
    Release (a)

The keyboard state tracker doesn't take this into account, so it is
surpressing all except the first Press event.

This might affect other frontends too if they use the same trick for
key repeat

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] Key repeat is no longer working on TTY and grub menu

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> Yes, this is another regression accidentally introduced by the keyboard
> state tracker.
>
> When GTK does key repeat it omits the Up event for repeated keys.
>
> IOW, you get
>
>     Press (a)
>     Press (a)
>     Press (a)
>     Release (a)

This is how keyboards commonly do it, if I remember correctly.

> Not
>
>     Press (a)
>     Release (a)
>     Press (a)
>     Release (a)
>     Press (a)
>     Release (a)
>
> The keyboard state tracker doesn't take this into account, so it is
> surpressing all except the first Press event.
>
> This might affect other frontends too if they use the same trick for
> key repeat

Plausible.

Re: [Qemu-devel] Key repeat is no longer working on TTY and grub menu

[Gerd Hoffmann]

On Wed, Feb 13, 2019 at 07:01:35AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > Yes, this is another regression accidentally introduced by the keyboard
> > state tracker.
> >
> > When GTK does key repeat it omits the Up event for repeated keys.
> >
> > IOW, you get
> >
> >     Press (a)
> >     Press (a)
> >     Press (a)
> >     Release (a)
> 
> This is how keyboards commonly do it, if I remember correctly.

Yes, this is pretty much what the hardware sends, intentionally, so the
software can figure whenever the event is a autorepeat event or not.

These days most software just ignores repeated events from the hardware
and generates them in software instead, to not depend on the keyboard
hardware capabilities for autorepeat.

> > This might affect other frontends too if they use the same trick for
> > key repeat
> 
> Plausible.

UIs are not consistent here.  But, yes, we probably should just allow
down events even if the key is already in down state.

cheers,
  Gerd