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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] monitor: intervally send down events to guest in hold time
Date: Mon, 22 Apr 2013 16:32:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

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



reply via email to

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