From: Paolo Bonzini <pbonzini@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>, Amos Kong <akong@redhat.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
Eric Blake <eblake@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] monitor: intervally send down events to guest in hold time
Date: Mon, 22 Apr 2013 16:32:18 +0200 [thread overview]
Message-ID: <517549F2.3020809@redhat.com> (raw)
In-Reply-To: <51753C8B.5080504@redhat.com>
Il 22/04/2013 15:35, Gerd Hoffmann ha scritto:
> Hi,
>
>>> But isn't this patch the equivalent of repeatedly pressing and releasing a
>>> key? Shouldn't this be implemented at a lower-level layer like the input
>>> subsystem?
>
> ps/2 keyboard emulation would probably the place to do it.
Yes, if PS/2 keyboard emulation emulated the autorepeat rate/delay, then
the code we have in QMP would just work. However it would need to be
done for all devices (ignoring repeated keydown events from the upper
layers, and creating its own repeated event). So it makes sense to have
it in common code and have keyboard devices just tell common code the
desired rate/delay.
BTW, how do we currently handle stuck keys across migration (where the
key-up event never reaches the guest because the key was never pressed
in the first place on the destination)?
> I'm pretty sure not all keyboard types have auto-repeat. The linux
> kernel input layer has code to generate the auto-repeat kbd events in
> software, and that code is there for a reason I guess ...
Yes. Or simply it is easier to put it there than in all keyboard
drivers. The USB keyboard for example has a hybrid hardware/software
autorepeat, where the OS must pass the delay to the next key after each
keypress.
>> No, this patch is implementing what the microcontroller does, i.e. 10
>> presses + 1 release. I'm not sure it is the right level to do it (the
>> rate/delay should be at least customizable from the board), but the
>> logic is right and if someone else needs more configurability we can add
>> it later.
>
> IIRC the (ps/2) kbd controller can be programmed with rate+delay.
Yes, but we ignore the command. For the PS/2 keyboard, I think what we
send now to the guest is based on the rate/delay that is emulated in
software by the GUI layers (for Unix it should just be X11 for all of
SDL/VNC/Spice).
With a FreeDOS image it is easy to test, you can see that the USB
keyboard has a longer delay than the text console. The PS/2 keyboard
instead has roughly the same delay.
Paolo
next prev parent reply other threads:[~2013-04-22 14:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-19 4:44 [Qemu-devel] [PATCH] monitor: intervally send down events to guest in hold time Amos Kong
2013-04-20 16:06 ` Eric Blake
2013-04-22 7:32 ` Amos Kong
2013-04-22 8:09 ` Amos Kong
2013-04-22 9:33 ` Paolo Bonzini
2013-04-22 12:43 ` Luiz Capitulino
2013-04-22 13:03 ` Paolo Bonzini
2013-04-22 13:35 ` Gerd Hoffmann
2013-04-22 14:32 ` Paolo Bonzini [this message]
2013-04-22 15:20 ` Gerd Hoffmann
2013-04-22 15:41 ` Paolo Bonzini
2013-04-22 14:02 ` Anthony Liguori
2013-04-22 14:22 ` Luiz Capitulino
2013-04-23 2:24 ` Amos Kong
2013-04-22 8:25 ` [Qemu-devel] [PATCH] ui/input.c: replace magic numbers by macros Amos Kong
2013-04-22 16:25 ` [Qemu-devel] [PATCH] monitor: intervally send down events to guest in hold time Eric Blake
2013-05-14 12:42 ` Laszlo Ersek
2013-05-14 14:55 ` Anthony Liguori
2013-05-15 8:13 ` Amos Kong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=517549F2.3020809@redhat.com \
--to=pbonzini@redhat.com \
--cc=akong@redhat.com \
--cc=eblake@redhat.com \
--cc=kraxel@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).