On Tue, Jul 27, 2004 at 10:45:26PM -0300, Rob Shortt wrote: > Ville Syrj�l� wrote: > >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.
Since you're using fusion you could start whatever app you're running and run dfblayer from another ssh shell. > >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 don't think there's much point in going that far. If an app uses something else than the primary layer then it certainly should know what it's doing and configure the pixelformat properly. > 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. So you just changed the the pixelformat in crtc2InitLayer()? That should have solved your problems. <snip> > 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? CRTC2 doesn't support LUT8. I'm not sure what's going on with this hack. -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/
