On Tue, Feb 12, 2008 at 03:01:53PM +0100, Denis Oliver Kropp wrote:
> Marco Cavallini [KOAN] wrote:
> > Attached my temporary DirectFB-1.1.1 patch for BGR24 color support for
> > board based on AT91SAM9263 cpu
> >
> > Work is in progress and and I'm still facing to some errors so any
> > comment or help would be greatly appreciated.
> > TIA
> >
> >
> > Cordiali Saluti / Kindest Regards / mit freundlichen Grüssen
>
> Gratias ago!
>
> Wait, looking at the RGB24 case, should this be endianness dependent?
>
> case DSPF_RGB24:
> for (n=0, n3=0; n<surface->config.size.w; n++, n3+=3) {
> #ifdef WORDS_BIGENDIAN
> buf_p[n3+0] = data8[n3+0];
> buf_p[n3+1] = data8[n3+1];
> buf_p[n3+2] = data8[n3+2];
> #else
> buf_p[n3+0] = data8[n3+2];
> buf_p[n3+1] = data8[n3+1];
> buf_p[n3+2] = data8[n3+0];
> #endif
> }
> break;
>
>
> RGB24 is weird. Does anybody know which is the real standard byte order and
> endianness dependency?
I don't think anyone agrees on this stuff. Many people don't even agree
how the easier formats are arranged (ie. sometimes when you read the
name left-to-right is msb-to-lsb, sometimes the other way around).
One thing that might serve as a rule is that you should be able to copy
RGB32 to RGB24 by simply walking both streams byte at a time and
copying the relevant bytes (and skipping the extra bytes in RGB32). And
since out RGB32 is native endian that implies that RGB24/BGR24 are
stored in native endian format as well.
I suppose the really important question is how does typical hardware
arrange this.
> diff -urNp DirectFB-1.1.1-orig/systems/fbdev/fbdev.c
> DirectFB-1.1.1-bgr24/systems/fbdev/fbdev.c
> --- DirectFB-1.1.1-orig/systems/fbdev/fbdev.c 2008-01-18 21:29:37.000000000
> +0100
> +++ DirectFB-1.1.1-bgr24/systems/fbdev/fbdev.c 2008-02-09
> 11:49:32.000000000 +0100
> @@ -1505,9 +1505,11 @@ static DFBSurfacePixelFormat dfb_fbdev_g
> break;
>
> case 24:
> - if (dfb_fbdev_compatible_format( var, 0, 8, 8, 8, 0, 16, 8, 0
> ))
> + if (dfb_fbdev_compatible_format( var, 0, 8, 8, 8, 0, 16, 8, 0 ))
> return DSPF_RGB24;
> -
> + if (dfb_fbdev_compatible_format( var, 0, 8, 8, 8, 8, 16, 0, 0
> )) // BGR24 (MCK)
>
>
> =======> What does fbset -i tell you?
If it's native endian BGR then AFAICS dfb_fbdev_compatible_format( var, 0, 8,
8, 8, 0, 0, 8 16 )
should be the correct form. Then again I'm not entirely sure how the fbdev API
should be really
used. If you look at the fb.h header file you can see this:
/* Interpretation of offset for color fields: All offsets are from the right,
* inside a "pixel" value, which is exactly 'bits_per_pixel' wide (means: you
* can use the offset as right argument to <<). A pixel afterwards is a bit
* stream and is written to video memory as that unmodified. This implies
* big-endian byte order if bits_per_pixel is greater than 8.
*/
struct fb_bitfield {
__u32 offset; /* beginning of bitfield */
__u32 length; /* length of bitfield */
__u32 msb_right; /* != 0 : Most significant bit is */
/* right */
};
I can understand the offset/length thing but then it goes on to mention
the big-endian byte order. I don't quite get what it's trying to say.
Perhaps the designer simply didn't believe little-endian hardware would
be ever used :)
I think atmel_lcdfb was mentioned in an earlier thread so I took a quick
look at the driver and for it the dfb_fbdev_compatible_format() should be
exactly what I suggested above. Looks like it uses ABGR8888 @ 32bpp, and
BGR555 @ 16bpp. IIRC the AT91 LCDC has a big-endian bit somewhere that
can do some swapping but I don't know how it would behave (it would
at least screw up 16bpp if it's just swaps the bytes, and if it just
swaps halfwords in 16bpp mode it would be useless for non mixed-endian
case).
BTW looks like RGB24 software rendering code doesn't take endianness
into consideration so it could use some fixes too when BGR24 is added.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
