Patchwork Add QEMU DirectFB display driver

login
register
mail settings
Submitter Gerd Hoffmann
Date May 18, 2010, 10 p.m.
Message ID <4BF30E15.6040505@redhat.com>
Download mbox | patch
Permalink /patch/52924/
State New
Headers show

Comments

Gerd Hoffmann - May 18, 2010, 10 p.m.
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 reference.

Same bug as SDL on framebuffer:  No sane console switching.  Boot a 
guest, switch to another (host) virtual terminal, watch qemu continue 
drawing on your screen.

Guys, this is simply not acceptable.  You are not alone on the machine. 
  If I switch away to another virtual terminal I want to see that other 
terminals content and nothing else.

NACK.

cheers,
   Gerd
From 50f26301ba1f8a0588fcafc54b05fe508e084696 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon, 17 May 2010 13:54:59 +0200
Subject: [PATCH] fixups

---
 configure       |   18 +++++++++++++-----
 qemu-options.hx |    3 ++-
 2 files changed, 15 insertions(+), 6 deletions(-)
Stefano Stabellini - May 19, 2010, 12:06 p.m.
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 hacking configure to use pkgconfig.  Patch 
> attached for reference.
> 
> Same bug as SDL on framebuffer:  No sane console switching.  Boot a 
> guest, switch to another (host) virtual terminal, watch qemu continue 
> drawing on your screen.
> 
> Guys, this is simply not acceptable.  You are not alone on the machine. 
>   If I switch away to another virtual terminal I want to see that other 
> terminals content and nothing else.
> 
> NACK.


I completely agree with you.

I think the only way to fix this is to handle VT acquire and release
events ourselves.
At this point I am not sure if it is worth doing it in the DirectFB
frontend or in the SDL frontend directly (making sure we are not
running on X11 first).
Gerd Hoffmann - May 19, 2010, 1:38 p.m.
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 directly (making sure we are not
> running on X11 first).

I didn't investigate who is at fault here.  SDL docs doesn't mention 
console switching at all it seems (grep -i console in 
/usr/share/doc/SDL-devel-1.2.13/html doesn't find me anything).  Which 
makes me assume no special actions by the app using SDL are required for 
it.  Which in turn makes me think SDL is broken.

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.

cheers,
   Gerd
Stefano Stabellini - May 19, 2010, 1:52 p.m.
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 worth doing it in the DirectFB
> > frontend or in the SDL frontend directly (making sure we are not
> > running on X11 first).
> 
> I didn't investigate who is at fault here.  SDL docs doesn't mention 
> console switching at all it seems (grep -i console in 
> /usr/share/doc/SDL-devel-1.2.13/html doesn't find me anything).  Which 
> makes me assume no special actions by the app using SDL are required for 
> it.  Which in turn makes me think SDL is broken.
> 
> 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 was thinking the same thing.
The only reason for using a library is to have the color/pixel conversion
functions, that could be useful. However we have many of them already
implemented in qemu so it shouldn't be difficult to roll our own.

Julian, what do you think?
Gerd Hoffmann - May 19, 2010, 3:22 p.m.
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 was thinking the same thing.
> The only reason for using a library is to have the color/pixel conversion
> functions, that could be useful. However we have many of them already
> implemented in qemu so it shouldn't be difficult to roll our own.

Everybody implements its own conversion functions though.  It probably 
makes sense to consolidate that stuff into a small conversion library, 
probably best based on PixelFormat, and make everybody use that.

cheers,
   Gerd
Stefano Stabellini - May 19, 2010, 3:30 p.m.
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 (IMHO pointless) video mode switching bits.
> >
> > Agreed, actually I was thinking the same thing.
> > The only reason for using a library is to have the color/pixel conversion
> > functions, that could be useful. However we have many of them already
> > implemented in qemu so it shouldn't be difficult to roll our own.
> 
> Everybody implements its own conversion functions though.  It probably 
> makes sense to consolidate that stuff into a small conversion library, 
> probably best based on PixelFormat, and make everybody use that.
> 
 
Yeah definitely
Julian Pidancet - May 19, 2010, 4:06 p.m.
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 work out.
>>
>>> At this point I am not sure if it is worth doing it in the DirectFB
>>> frontend or in the SDL frontend directly (making sure we are not
>>> running on X11 first).
>>
>> I didn't investigate who is at fault here.  SDL docs doesn't mention 
>> console switching at all it seems (grep -i console in 
>> /usr/share/doc/SDL-devel-1.2.13/html doesn't find me anything).  Which 
>> makes me assume no special actions by the app using SDL are required for 
>> it.  Which in turn makes me think SDL is broken.
>>
>> 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 was thinking the same thing.
> The only reason for using a library is to have the color/pixel conversion
> functions, that could be useful. However we have many of them already
> implemented in qemu so it shouldn't be difficult to roll our own.
> 
> Julian, what do you think?
> 

It also appears to me to be the good way to do this thing.

Gerd, it is true that the DirectFB suffers the same problem as the SDL driver regarding the VT switching. Actually I investigated the issue yesterday, and I found out that:
 1) even though there is some VT handling in DirectFB, it is incomplete (I found "to be finished" mentions in the TODO file).
 2) When we switch to another VT, Qemu continues to draw on the screen using the pointer acquired from DirectFB. There's no hooks we can set in DirectFB's VT code for Qemu to be notified when we change VT, in order to stop drawing.

So, even though DirectFB claims to handle multiple VTs, I agree that it currently sucks.

So after all, why not implementing our own VT switching and using directly the fbdev interface. I just checked the linux fbdev code to find out if it provides with a blitting method that could perform the pixel color conversion automatically for Qemu. 

Unfortunately, from what I have read from the drivers/video/cfbimgblt.c file in the linux tree, there's no such thing, and it also means that we cannot take advantage of any kind of hardware pixel format conversion.

But anyway, I don't think software color conversion would be a problem, because it already exists in several places in Qemu.
Jamie Lokier - May 19, 2010, 4:30 p.m.
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 too.

> I just checked the linux fbdev code to
> find out if it provides with a blitting method that could perform
> the pixel color conversion automatically for Qemu.
> 
> Unfortunately, from what I have read from the
> drivers/video/cfbimgblt.c file in the linux tree, there's no such
> thing, and it also means that we cannot take advantage of any kind
> of hardware pixel format conversion.

I'm not sure if DirectFB provides that particular operation, but I
have the impression it's the sort of thing DirectFB is intended for: A
framebuffer, plus a variety of 2d acceleration methods (and other
things like multi-buffering, video and alpha channel overlay).

-- Jamie
Gerd Hoffmann - May 20, 2010, 7:32 a.m.
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.

> Being able to tell qemu, through the monitor, to attach/detach from a
> particular VT might be a nice easy bonus too.

Yes, should be doable without too much effort.

>> I just checked the linux fbdev code to
>> find out if it provides with a blitting method that could perform
>> the pixel color conversion automatically for Qemu.
>>
>> Unfortunately, from what I have read from the
>> drivers/video/cfbimgblt.c file in the linux tree, there's no such
>> thing, and it also means that we cannot take advantage of any kind
>> of hardware pixel format conversion.
>
> I'm not sure if DirectFB provides that particular operation, but I
> have the impression it's the sort of thing DirectFB is intended for: A
> framebuffer, plus a variety of 2d acceleration methods (and other
> things like multi-buffering, video and alpha channel overlay).

As far I know acceleration depends on the directfb kernel drivers 
though, i.e. in 99% of the cases (standard distro installs) those are 
not available and software fallbacks are active anyway.  So from a 
performance point of view directfb doesn't buy us much.  And for the 
pixel conversion I'd prefer see some reorganization of the existing qemu 
code which is spread all over the place now ...

cheers,
   Gerd

Patch

diff --git a/configure b/configure
index b453e85..de4bf8f 100755
--- a/configure
+++ b/configure
@@ -258,7 +258,7 @@  kvm=""
 kvm_para=""
 nptl=""
 sdl=""
-directfb="no"
+directfb=""
 sparse="no"
 uuid=""
 vde=""
@@ -1071,10 +1071,18 @@  fi
 ##########################################
 # DirectFB probe
 
-if test "$directfb" = "yes" ; then
-  directfb_libs=`directfb-config --libs`
-  directfb_cflags=`directfb-config --cflags`
-  libs_softmmu="$directfb_libs $libs_softmmu"
+if test "$directfb" != "no" ; then
+  if $pkgconfig directfb; then
+    directfb_libs=$($pkgconfig directfb --libs)
+    directfb_cflags=$($pkgconfig directfb --cflags)
+    libs_softmmu="$directfb_libs $libs_softmmu"
+    directfb=yes
+  else
+    if test "$directfb" = "yes" ; then
+      feature_not_found "directfb"
+    fi
+    directfb=no
+  fi
 fi
 
 ##########################################
diff --git a/qemu-options.hx b/qemu-options.hx
index a4bdfbe..9597a48 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -610,7 +610,8 @@  ETEXI
 
 #ifdef CONFIG_DIRECTFB
 DEF("directfb", 0, QEMU_OPTION_directfb,
-    "-directfb       enable DirectFB\n")
+    "-directfb       enable DirectFB\n",
+    QEMU_ARCH_ALL)
 #endif
 STEXI
 @item -directfb