On Tue, May 14, 2013 at 09:55:26AM -0500, Anthony Liguori wrote:
> Laszlo Ersek writes:
> > What's the status of this patch if I may ask?
>
> 1) It's unclear if this is the right solution. If key repeat is done in
> the PS/2 controller, then that's where the logic here should be.
It's best t
Laszlo Ersek writes:
> Hi,
>
> On 04/19/13 06:44, Amos Kong wrote:
>> (qemu) sendkey a 1000
>>
>> Current design is that qemu only send one down event to guest,
>> and delay sometime, then send one up event. In this case, only
>> key can be identified by guest.
>>
>> This patch changed qemu to
Hi,
On 04/19/13 06:44, Amos Kong wrote:
> (qemu) sendkey a 1000
>
> Current design is that qemu only send one down event to guest,
> and delay sometime, then send one up event. In this case, only
> key can be identified by guest.
>
> This patch changed qemu to intervally send down events to gues
On Mon, Apr 22, 2013 at 09:02:41AM -0500, Anthony Liguori wrote:
> Paolo Bonzini 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 r
On 04/22/2013 01:32 AM, Amos Kong wrote:
> On Sat, Apr 20, 2013 at 10:06:28AM -0600, Eric Blake wrote:
>> On 04/18/2013 10:44 PM, Amos Kong wrote:
>>> (qemu) sendkey a 1000
>>>
>>> Current design is that qemu only send one down event to guest,
>>> and delay sometime, then send one up event. In this
Il 22/04/2013 17:20, Gerd Hoffmann ha scritto:
>> > 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 creatin
Hi,
> 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 hav
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,
On Mon, 22 Apr 2013 09:02:41 -0500
Anthony Liguori wrote:
> Paolo Bonzini 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 regist
Paolo Bonzini 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
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.
I'm pretty sure not all keyboard types have auto-repeat. The l
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,
On Mon, 22 Apr 2013 11:33:20 +0200
Paolo Bonzini wrote:
> Il 22/04/2013 10:09, Amos Kong ha scritto:
> > On Mon, Apr 22, 2013 at 03:32:52PM +0800, Amos Kong wrote:
> >> On Sat, Apr 20, 2013 at 10:06:28AM -0600, Eric Blake wrote:
> >>> On 04/18/2013 10:44 PM, Amos Kong wrote:
> (qemu) sendkey
Il 22/04/2013 10:09, Amos Kong ha scritto:
> On Mon, Apr 22, 2013 at 03:32:52PM +0800, Amos Kong wrote:
>> On Sat, Apr 20, 2013 at 10:06:28AM -0600, Eric Blake wrote:
>>> On 04/18/2013 10:44 PM, Amos Kong wrote:
(qemu) sendkey a 1000
Current design is that qemu only send one down eve
On Mon, Apr 22, 2013 at 03:32:52PM +0800, Amos Kong wrote:
> On Sat, Apr 20, 2013 at 10:06:28AM -0600, Eric Blake wrote:
> > On 04/18/2013 10:44 PM, Amos Kong wrote:
> > > (qemu) sendkey a 1000
> > >
> > > Current design is that qemu only send one down event to guest,
> > > and delay sometime, the
On Sat, Apr 20, 2013 at 10:06:28AM -0600, Eric Blake wrote:
> On 04/18/2013 10:44 PM, Amos Kong wrote:
> > (qemu) sendkey a 1000
> >
> > Current design is that qemu only send one down event to guest,
> > and delay sometime, then send one up event. In this case, only
> > key can be identified by gu
On 04/18/2013 10:44 PM, Amos Kong wrote:
> (qemu) sendkey a 1000
>
> Current design is that qemu only send one down event to guest,
> and delay sometime, then send one up event. In this case, only
> key can be identified by guest.
>
> This patch changed qemu to intervally send down events to gues
(qemu) sendkey a 1000
Current design is that qemu only send one down event to guest,
and delay sometime, then send one up event. In this case, only
key can be identified by guest.
This patch changed qemu to intervally send down events to guest
in the hold time, the interval is 100ms.
(qemu) send
18 matches
Mail list logo
