Re: [Qemu-devel] [PATCH] hid: Extend the event queue size to 1024

[Alexander Graf <agraf@suse.de>]

On 18.04.16 11:21, Gerd Hoffmann wrote:
> On Mo, 2016-04-18 at 09:26 +0200, Alexander Graf wrote:
>>
>> On 18.04.16 08:53, Gerd Hoffmann wrote:
>>>   Hi,
>>>
>>>> Vnc already uses qemu_input_event_send_key_delay today, so I'm not sure 
>>>> where things fall apart.
>>>
>>> Well, not everywhere.  Try the attached patch.
>>>
>>> Also worth trying:
>>>  * use xhci instead of ohci (current slof should handle
>>>    kbd-via-xhci fine)
>>>  * use virtio-keyboard (no slof driver yet as far I know, also needs
>>>    a recent linux kernel).
>>
>> Ideally I would really like to switch to virtio-input and virtio-gpu for
>> AArch64, but there are no drivers at all in OVMF. Do you have any plans
>> to write them?
> 
> Not investigated yet.  There are virtio 1.0 patches in flight for edk2,
> once they are landed it should be alot simpler (virtio 1.0 is mandatory
> for virtio-gpu and virtio-input).
> 
> Keyboard should be easy, it's a simple device.
> 
> GPU is tricky.  Guest is expected to explicitly request display updates.
> So simply setting up a dump framebuffer, then depending on dirty page
> tracking for screen updates isn't going to fly.  Not sure EFI can handle
> that.

It should. The GOP interface usually gets invoked with special BLT
callbacks that copy gfx data from the payload to the frame buffer. Of
course we would need to make sure we don't set the magical "this is
where the frame buffer is, please use it" bit, as otherwise Linux would
try to access it as efifb.

> The virtio-vga device has a vga compatibility mode additionally to
> native virtio.  SLOF uses that IIRC.  But I think on aarch64 that isn't
> going to fly either due to the cache coherency issues there.

Exactly, so a native virtio-gpu driver would be the best option for us
here. Once Linux takes over, it can just switch to its own virtio-gpu
driver.


Alex