Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Alexander Graf]

On 18.05.2010, at 00:47, Anthony Liguori wrote:

> On 05/17/2010 05:42 PM, malc wrote:
>>> In fact, couldn't we rather keep all graphic output out of qemu and
>>> just expose VNC, possibly with self-made additions to the protocol
>>> to speed up local rendering (thinking an SHM extension here)? Then
>>> we could still offer a separate SDL based viewer that could do the
>>> same things it does now. But we'd also open up the gate for a whole
>>> new integration level with possible GUIs.
>>> 
>>>     
>> This idea is not new, nothing has come out of it till this day, so the
>> answer to your question (couldn't we...) is probably: no, we couldn't.
>>   
> 
> Because shared memory is just a graphics optimization and for most users, the 
> difference between gtk-vnc and native SDL isn't noticable.  So if a shared 
> memory transport was the key missing piece, we'd have an awesome GUI based on 
> gtk-vnc that just had slower graphics.

Well, there's also the missing QMP part :)

> IMHO, the problem with an external GUI is that the interaction just gets too 
> complicated.

What interaction do you mean? I'm not advocating to move the GUI to a different 
project. I was more thinking of a separation like with perf where the kernel 
side does the recording and the userspace side does the displaying of profiling 
results. Qemu would run the VM and the tightly coupled viewer app would show it.

If you like, we could even move the backend qemu to "qemu-backend" and have the 
normally invoked binaries be the GUI application that just runs the respective 
qemu-backend application. That way it'd be 100% seamless for the average user, 
but qemu -demonize becomes really powerful.


Alex