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