On 8/1/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
Albert Torras wrote:
>
>
> On 7/29/06, *Denis Oliver Kropp* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>
> Most of the CPU access to the frame buffer happens in the software
> rendering code in src/gfx/generic/generic.c, but there's also some
> code in src/core/surfacemanager.c for "upload/download" of buffers.
>
> Another place is src/misc/gfx_util.c for scaling and converting
> (loaded) image data to the various formats a surface can have.
>
> Furthermore, applications can also access the framebuffer using the
> public API IDirectFBSurface::Lock().
>
> Endianness problems? Or no direct mapping of the framebuffer?
>
> --
> Best regards,
> Denis Oliver Kropp
>
>
>
>
> Hi,
>
> as I am working with a Motorola CPU, I defined WORDS_BIGENDIAN in
> config.h in order to solve the possible endianness problem.
>
> I have seen the DirectFB library detects my framebuffer works with
> ARGB1555, when it actually does with RGB16.
>
> How can this be possible? Is there any way to solve this?
You can hack the detection in systems/fbdev/fbdev.c or fix the
frame buffer driver.
> I have tried to adjust colors manually, but without success...
If you have a big endian CPU with a little endian bus it's not easy...
--
Is the detection done in "static DFBSurfacePixelFormat dfb_fbdev_get_pixelformat( struct fb_var_screeninfo *var )" ??
I will try in a couple of days... I hope it works.
Regards,
Albert Torras
_______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
