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

[Julian Pidancet <julian.pidancet@citrix.com>]

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