| Message ID | 4BF30E15.6040505@redhat.com |
|---|---|
| State | New |
| Headers | show |
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).
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
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?
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
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
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.
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
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
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