From: Amos Kong <akong@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
jan.kiszka@siemens.com, kraxel@redhat.com,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] monitor: intervally send down events to guest in hold time
Date: Tue, 23 Apr 2013 10:24:56 +0800 [thread overview]
Message-ID: <20130423022456.GA2234@t430s.nay.redhat.com> (raw)
In-Reply-To: <87vc7ewtmm.fsf@codemonkey.ws>
On Mon, Apr 22, 2013 at 09:02:41AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
> > Il 22/04/2013 14:43, Luiz Capitulino ha scritto:
> >>> >
> >>> > You're right. The typematic delay/rate is implemented within the i8042
> >>> > keyboard microcontroller (QEMU does not implement that register).
> >>> >
> >>> > It is possible that software ignores interrupts for a key that is
> >>> > already down, and reimplements autorepeat in software, but your patch is
> >>> > correct.
> >> 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?
> >
> > 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.
>
> Regardless, this is a compat breaker IMHO. This is a dramatically
> different semantic behavior.
>
> What's the use-case here?
I don't if we have some new use-cases now.
Original case:
| commit c8256f9d23bba4fac3b0b6a9e6e3dc12362cbe0b
| Author: balrog <balrog@c046a42c-6fe2-441c-8c8c-71466251a162>
| Date: Sun Jun 8 22:45:01 2008 +0000
|
| Enhance sendkey with key hold time (Jan Kiszka).
|
| Current key injection via the monitor basically generates no key hold
| time. This is fine for keyboard emulations that have their own queues,
| but it causes troubles for those how don't (like the MusicPal - it
| simply does not work with injected keys). Moreover, I would like to use
| this mechanism to simulate pressed buttons during power-up.
|
| Therefore, this patch enhances the key injection with a configurable
| release delay (by default 100 virtual milliseconds).
Original hold only casused the release delay, it didn't mention the
auto-repeate.
| This feature allows to get rid of the initial sleep() in musicpal_init
| because one can now simply start qemu with -S and issue "sendkey m 1000"
| and "continue" in the monitor to achieve the desired effect of a pressed
| menu button during power-up. So there is no need for a per-musicpal or
| even qemu-wide "-hold-button" switch.
Before my patch, I started a guest with '-boot menu=on -S' option, executed
(qemu) sendkey f12 2000
(qemu) cont
Boot menu can't be enabled.
Applied my patch, do the same test, Boot menu can be enabled.
| Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
--
Amos.
next prev parent reply other threads:[~2013-04-23 2:25 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
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 [this message]
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=20130423022456.GA2234@t430s.nay.redhat.com \
--to=akong@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=jan.kiszka@siemens.com \
--cc=kraxel@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=pbonzini@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).