|Site sponsored by IGEL|
[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.
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.A quick fix is simply changing the format with dfblayer.
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.
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.Do these apps just need to be updated to DirectFB CVS or have things changed with how the G400 CRTC2 works?
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:
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 @@
- 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 );
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?