On 05/19/10 18:30, Jamie Lokier wrote:
Julian Pidancet wrote:
So after all, why not implementing our own VT switching and using
directly the fbdev interface.
It's a good idea. VT switching isn't hard to track reliably.
Indeed, only problem is that the fbdev libs usually want to do that too.
Julian Pidancet wrote:
> So after all, why not implementing our own VT switching and using
> directly the fbdev interface.
It's a good idea. VT switching isn't hard to track reliably.
Being able to tell qemu, through the monitor, to attach/detach from a
particular VT might be a nice easy bonus t
On 05/19/2010 02:52 PM, Stefano Stabellini wrote:
> On Wed, 19 May 2010, Gerd Hoffmann wrote:
>>Hi,
>>
>>> I think the only way to fix this is to handle VT acquire and release
>>> events ourselves.
>>
>> Hmm. I suspect sdl and directfb wanna do this too, so I'm not sure this
>> will actually
On Wed, 19 May 2010, Gerd Hoffmann wrote:
>Hi,
>
> >> Which makes me think we should just go the direct route. No SDL. No
> >> directfb. No other funky library which provides us with nothing but
> >> bugs. Programming fbdev isn't that hard after all. Especially if you
> >> skip all the (I
Hi,
Which makes me think we should just go the direct route. No SDL. No
directfb. No other funky library which provides us with nothing but
bugs. Programming fbdev isn't that hard after all. Especially if you
skip all the (IMHO pointless) video mode switching bits.
Agreed, actually I wa
On Wed, 19 May 2010, Gerd Hoffmann wrote:
>Hi,
>
> > I think the only way to fix this is to handle VT acquire and release
> > events ourselves.
>
> Hmm. I suspect sdl and directfb wanna do this too, so I'm not sure this
> will actually work out.
>
> > At this point I am not sure if it is w
Hi,
I think the only way to fix this is to handle VT acquire and release
events ourselves.
Hmm. I suspect sdl and directfb wanna do this too, so I'm not sure this
will actually work out.
At this point I am not sure if it is worth doing it in the DirectFB
frontend or in the SDL frontend
On Tue, 18 May 2010, Gerd Hoffmann wrote:
> On 05/13/10 17:53, Julian Pidancet wrote:
> > This patch implements a DirectFB driver for QEMU. It allows Qemu to
> > draw a VM graphic output directly in the framebuffer of the host,
> > without having to rely on X11.
>
> Managed to build it after hacki
On 05/13/10 17:53, Julian Pidancet wrote:
This patch implements a DirectFB driver for QEMU. It allows Qemu to
draw a VM graphic output directly in the framebuffer of the host,
without having to rely on X11.
Managed to build it after hacking configure to use pkgconfig. Patch
attached for refer
On 05/18/2010 03:09 AM, Kevin Wolf wrote:
Am 17.05.2010 23:43, schrieb Anthony Liguori:
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.
On 05/18/10 12:34, Stefano Stabellini wrote:
I am curious about one thing: if the spice client is running on the same
host as the VM and qemu, is there any plan for sharing memory somehow
between the two components? OR is it not believed to be necessary to
reach good performances?
Well. We do
On Tue, 18 May 2010, Gerd Hoffmann wrote:
> On 05/18/10 11:29, Stefano Stabellini wrote:
> > On Tue, 18 May 2010, Gerd Hoffmann wrote:
> >> On 05/18/10 11:12, Stefano Stabellini wrote:
> >>> I think it would be better to implement an accelerated frontend for
> >>> rendering the framebuffer, like op
On Tue, 18 May 2010, Gerd Hoffmann wrote:
> On 05/18/10 11:12, Stefano Stabellini wrote:
> > I think it would be better to implement an accelerated frontend for
> > rendering the framebuffer, like opengl or xv.
>
> Well. xv is pretty pointless IMHO. gl makes sense. But to have some
> effect th
On 05/18/10 11:29, Stefano Stabellini wrote:
On Tue, 18 May 2010, Gerd Hoffmann wrote:
On 05/18/10 11:12, Stefano Stabellini wrote:
I think it would be better to implement an accelerated frontend for
rendering the framebuffer, like opengl or xv.
Well. xv is pretty pointless IMHO. gl makes s
On 05/18/10 11:12, Stefano Stabellini wrote:
I think it would be better to implement an accelerated frontend for
rendering the framebuffer, like opengl or xv.
Well. xv is pretty pointless IMHO. gl makes sense. But to have some
effect this needs some major restructions in qemu, the current
Am 17.05.2010 23:43, schrieb Anthony Liguori:
> 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 t
On Tue, 18 May 2010, Kevin Wolf wrote:
> Am 17.05.2010 23:43, schrieb Anthony Liguori:
> > 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.
>
On 05/17/2010 05:55 PM, Alexander Graf wrote:
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 ke
On 18.05.2010, at 00:54, Anthony Liguori wrote:
> On 05/17/2010 05:49 PM, Alexander Graf wrote:
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.
>
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)? Th
On 05/17/2010 05:49 PM, Alexander Graf wrote:
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.
You could, but I think it introduces more complexity wh
On 18.05.2010, at 00:46, Anthony Liguori wrote:
> On 05/17/2010 05:26 PM, Alexander Graf wrote:
>> 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 stri
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
On 05/17/2010 05:26 PM, Alexander Graf wrote:
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.
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
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.
>>>
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
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.
On Mon, 17 May 2010, Anthony Liguori wrote:
> On 05/17/2010 03:20 PM, Gerd Hoffmann wrote:
> > On 05/16/10 03:10, Paul Brook wrote:
> > > > The other solution would be to use the DirectFB driver for SDL which
> > > > would allow to do slightly the same as this patch. But that would mean
> > > > ha
On 05/17/2010 03:20 PM, Gerd Hoffmann wrote:
On 05/16/10 03:10, Paul Brook wrote:
The other solution would be to use the DirectFB driver for SDL which
would allow to do slightly the same as this patch. But that would mean
having to deal with an additional layer in the graphical stack,
which is
On 05/16/10 03:10, Paul Brook wrote:
The other solution would be to use the DirectFB driver for SDL which
would allow to do slightly the same as this patch. But that would mean
having to deal with an additional layer in the graphical stack, which is
not exactly what one wants from a performance o
On 05/17/10 14:04, Julian Pidancet wrote:
On 05/17/2010 11:53 AM, Gerd Hoffmann wrote:
+directfb="no"
Should be ="" (aka autodetect).
+if test "$directfb" = "yes" ; then
+ directfb_libs=`directfb-config --libs`
+ directfb_cflags=`directfb-config --cflags`
+ libs_softmmu="$directfb_lib
On 05/17/2010 10:09 AM, Julian Pidancet wrote:
On 05/17/2010 02:30 PM, Anthony Liguori wrote:
On 05/15/2010 08:10 PM, Paul Brook wrote:
The other solution would be to use the DirectFB driver for SDL which
would allow to do slightly the same as this patch. But that would mean
having to
On 05/17/2010 02:30 PM, Anthony Liguori wrote:
> On 05/15/2010 08:10 PM, Paul Brook wrote:
>>> The other solution would be to use the DirectFB driver for SDL which
>>> would allow to do slightly the same as this patch. But that would mean
>>> having to deal with an additional layer in the graphical
On 05/15/2010 08:10 PM, Paul Brook wrote:
The other solution would be to use the DirectFB driver for SDL which
would allow to do slightly the same as this patch. But that would mean
having to deal with an additional layer in the graphical stack, which is
not exactly what one wants from a performa
On Mon, May 17, 2010 at 01:14:05PM +0100, Julian Pidancet wrote:
> I have not heard about that, sorry.
> My test configuration has an i915-like Intel graphic card, and a nearly
> standard 2.6.32 linux kernel. No specific patching was required.
You're right. I've checked it and the horrible kerne
On 05/17/2010 12:44 PM, Christoph Hellwig wrote:
> On Fri, May 14, 2010 at 05:58:50PM +0100, Julian Pidancet wrote:
>> This patch implements a DirectFB driver for QEMU. It allows Qemu to
>> draw a VM graphic output directly in the framebuffer of the host,
>> without having to rely on X11.
>> Direct
On 05/17/2010 11:53 AM, Gerd Hoffmann wrote:
>> +directfb="no"
>
> Should be ="" (aka autodetect).
>
>> +if test "$directfb" = "yes" ; then
>> + directfb_libs=`directfb-config --libs`
>> + directfb_cflags=`directfb-config --cflags`
>> + libs_softmmu="$directfb_libs $libs_softmmu"
>> +fi
>
>
On Fri, May 14, 2010 at 05:58:50PM +0100, Julian Pidancet wrote:
> This patch implements a DirectFB driver for QEMU. It allows Qemu to
> draw a VM graphic output directly in the framebuffer of the host,
> without having to rely on X11.
> DirectFB also provides with a generic interface take advantag
Hi,
Can you provide some performance data to justify this since SDL provides
the same ability?
IMHO no performance data is needed to justify this because SDL running
on top of the linux framebuffer is simply unusable IMHO.
cheers,
Gerd
+directfb="no"
Should be ="" (aka autodetect).
+if test "$directfb" = "yes" ; then
+ directfb_libs=`directfb-config --libs`
+ directfb_cflags=`directfb-config --cflags`
+ libs_softmmu="$directfb_libs $libs_softmmu"
+fi
use pkgconfig here. directfb-config most likely is just a pkgconfig
On 16.05.2010, at 03:10, Paul Brook wrote:
>> The other solution would be to use the DirectFB driver for SDL which
>> would allow to do slightly the same as this patch. But that would mean
>> having to deal with an additional layer in the graphical stack, which is
>> not exactly what one wants fr
> The other solution would be to use the DirectFB driver for SDL which
> would allow to do slightly the same as this patch. But that would mean
> having to deal with an additional layer in the graphical stack, which is
> not exactly what one wants from a performance or a complexity point of
> view.
This patch implements a DirectFB driver for QEMU. It allows Qemu to
draw a VM graphic output directly in the framebuffer of the host,
without having to rely on X11.
DirectFB also provides with a generic interface take advantage of graphic
hardware acceleration for a bunch of different supported car
This patch implements a DirectFB driver for QEMU. It allows Qemu to
draw a VM graphic output directly in the framebuffer of the host,
without having to rely on X11.
DirectFB also provides with a generic interface take advantage of graphic
hardware acceleration for a bunch of different supported car
On 05/14/2010 11:58 AM, Julian Pidancet wrote:
This patch implements a DirectFB driver for QEMU. It allows Qemu to
draw a VM graphic output directly in the framebuffer of the host,
without having to rely on X11.
DirectFB also provides with a generic interface take advantage of graphic
hardware ac
This patch implements a DirectFB driver for QEMU. It allows Qemu to
draw a VM graphic output directly in the framebuffer of the host,
without having to rely on X11.
DirectFB also provides with a generic interface take advantage of graphic
hardware acceleration for a bunch of different supported car
47 matches
Mail list logo
