qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: malc
Subject: Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
Date: Tue, 18 May 2010 02:42:52 +0400 (MSD)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

On Tue, 18 May 2010, Alexander Graf wrote:

> 
> On 17.05.2010, at 23:45, malc wrote:
> 
> > On Mon, 17 May 2010, Anthony Liguori wrote:
> > 
> >> On 05/17/2010 04:35 PM, malc wrote:
> >>> There's one thing that SDL does marvelously well - it's just one fairly
> >>> small and self contained library that doesn't unleash dependency hell on
> >>> the user.
> >>> 
> >>>> The fact that we have cocoa support in the tree is basically an admission
> >>>> of
> >>>> failure with SDL.
> >>>> 
> >>> I don't think so, the way i see it: someone had an itch (i.e. an
> >>> application that does not integrate well with his windowing environment)
> >>> and he scratched it.
> >>> 
> >> 
> >> SDL doesn't integrate well into a modern Gnome desktop either.  I don't see
> >> why we have Cocoa and not Gtk.  If the answer is, someone needs to send
> >> patches, expect patches soon :-)
> >> 
> > 
> > If those patches don't try to force Gnome on me (by removing SDL that is
> > and being optional) let them come.
> 
> I'm trying to think of a project where the clean separation between
> multiple video outputs implemented in the backend and a separate
> frontend worked out. So far the only case that has a strikingly
> similar architecture coming to my mind is mplayer. And I wouldn't
> call mplayer's GUI story a huge success.

Xine, VLC do have something resembling this separation too. As for
mplayer's GUI, never used it, what i did (and still) use is my own
video output device for mplayer, which is a lot faster than Xv, or
anything else for that matter, on my hardware.

> 
> 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.

-- 
mailto:address@hidden



reply via email to

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