[Top][All Lists]
[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
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, (continued)
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Gerd Hoffmann, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Anthony Liguori, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, malc, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Anthony Liguori, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, malc, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Alexander Graf, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver,
malc <=
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Anthony Liguori, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Alexander Graf, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Anthony Liguori, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Anthony Liguori, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Alexander Graf, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Anthony Liguori, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Alexander Graf, 2010/05/17
- [Qemu-devel] qemu usage, K D, 2010/05/17
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Kevin Wolf, 2010/05/18
- Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver, Stefano Stabellini, 2010/05/18