qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] monitor: intervally send down events to guest i


From: Amos Kong
Subject: Re: [Qemu-devel] [PATCH] monitor: intervally send down events to guest in hold time
Date: Tue, 23 Apr 2013 10:24:56 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Apr 22, 2013 at 09:02:41AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <address@hidden> 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 <address@hidden>
| 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 <address@hidden>

-- 
                        Amos.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]