DirectFB - Home of the pragmatist Roadmap


[directfb-users] Re: G400 CRTC2 issues in CVS
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-users] Re: G400 CRTC2 issues in CVS



Ville Syrjälä wrote:
The reason is the chroma sub-sampling of YUV formats. To get corect results we'd need to blend between several pixels. And just fixing rgba_to_dst_format() wouldn't help much since the sotware accel code would need a lot of work as well.
That's certainly understandable.


A quick fix is simply changing the format with dfblayer.
That didn't seem to be a permantent solution in my case since the only dfb app running at all is dfblayer (nothing there to remember the change?), but I do get your point.


My plan is to fix things so that the pixelformat option will affect whatever layer is selected with the primary-layer option. Currently it only works for the fbdev layer.
Perhaps it would be even better if you could specify the formats of each and every layer. I went poking around matrox_crtc2.c and tried some formats besides YUY2 (RGB32, ARGB, AiRGB), with ill results. I no longer get the "unimplemented destination format" message but am left with a black screen. Perhaps a register got screwed up. After reverting my changes it took a cold boot to put things right.


Do these apps just need to be updated to DirectFB CVS or have things changed with how the G400 CRTC2 works?
I don't think anything has changed. It has always been like this.
Sorry, I guess I was just getting things mixed up with my cle266 which I haven't run for a while. I do distinctly remember running df_fire and friend on my television, it must have been with the epia.

So, I started to wonder because I have seen the unimplemented destination format" error before while using SDL's DirectFB output, and went looking through its code. At around line 423 of src/video/directfb/SDL_DirectFB_video.c (http://www.libsdl.org/cgi/cvsweb.cgi/SDL12/src/video/directfb/SDL_DirectFB_video.c?rev=1.18&content-type=text/x-cvsweb-markup) you will see it default to DSPF_LUT8 if the dst format fails, in my case YUY2.

if (DFBToSDLPixelFormat (dlc.pixelformat, vformat))
DFBToSDLPixelFormat (DSPF_LUT8, vformat);

So, I decided to try a quick little hack:

Index: src/misc/gfx_util.c
===================================================================
RCS file: /cvs/directfb/DirectFB/src/misc/gfx_util.c,v
retrieving revision 1.45
diff -u -r1.45 gfx_util.c
--- src/misc/gfx_util.c 8 Jun 2004 06:54:31 -0000 1.45
+++ src/misc/gfx_util.c 28 Jul 2004 01:07:18 -0000
@@ -124,7 +124,9 @@
break;

default:
- D_ONCE( "unimplemented destination format (0x%08x)", dst_format );
+ D_ONCE( "unimplemented destination format (0x%08x) trying DSPF_LUT8", dst_format );
+ if (palette)
+ *dst++ = dfb_palette_search( palette, r, g, b, a );
break;
}
}

Ok, that's going to screw some things up, and I don't know what it will do to other surfaces. I am doing some testing with pydfb and the image test now works (*YAY*). So, back to df_*.

df_andi: i get a nice green screen
df_dok: some tests get green or black screen, the rectangles, triangles, and lines work.
df_fire: black screen


Defaulting to DSPF_LUT8 allows some things to work, does it depend on the format of what you are trying to display? I guess I am trying to understand what lets the SDL DirectFB driver work to display everything.

On another note, if I try to use force-windowed using SDL then I end up with a pretty blue screen. Would that be related?

-Rob




Home | Main Index | Thread Index


directfb.org / Development / Old Archives