Re: [Qemu-devel] Ongoing changes to the displaying code

[Anthony Liguori <anthony@codemonkey.ws>]

David Turner wrote:
>
>
>     I think that's a better route to go for this sort of thing.  If
>     you think it's generally useful, I think it'd also be worthwhile
>     to host within the QEMU project.  I just don't think it's the
>     right thing to add into QEMU directly.
>
>
> For my specific needs, VNC and a separate GUI application are totally 
> overkill. However, it is true that QEMU itself absolutely doesn't 
> require to support any GUI jazz (you should probably let that to 
> forks/GUI wrappers instead).

I would think the ability to maintain your own GUI and therefore not 
have to fork QEMU would outweigh the "overkill" factor.

What specifically, do you consider to be overkill?  Are you afraid of 
the performance overhead of VNC?  Is the lack of VNC clients a problem 
(assuming you don't want a gtk dependency)?

I hear a lot of people say "VNC is overkill" but practically, it seems 
to work pretty well for this sort of thing (as evident by virt-manager) 
so I'm wondering what people are concerned about.  If it's performance, 
there are ways we can dramatically improve the performance localhost so 
that it should be equal to SDL.  If it's the gtk dependency, then we 
probably look at splitting up gtk-vnc to make the gtk dependency 
optional and allow other display types to be easily supported.

> On the other hand, it would be nice to have a slightly better way to 
> decouple display/events between the emulation and user-interaction 
> parts of the system. For example, I've attached the framebuffer 
> abstraction that I currently use in the Android emulator source code 
> (it's a well documented header file).
>
> It's basically a slightly better DisplayState, with explicit 
> producer/clients relationships and a global fifo used for 
> initialization/linking. I do not claim it is the absolute best way to 
> do it, just an example on how this can be implemented.

I'd like to avoid introducing another remove communication mechanism in 
QEMU.  VNC is extremely flexible so we should be able to do whatever we 
need to do with it.

Regards,

Anthony Liguori

> If someone's interested, I can probably provide a patch against the 
> QEMU svn sources.
>
> Regards,
>
> - Digit 
>  
>
>
>     Regards,
>
>     Anthony Liguori
>
>         Regards,
>
>         Anthony Liguori
>
>
>
>
>