Re: [F]Framebuffer driver using SM501 hardware.

On Wed, 17 Aug 2005, Andrey Volkov wrote:

Geert Uytterhoeven wrote:

quoted

On Wed, 17 Aug 2005, Andrey Volkov wrote:

quoted

Todo:
- 16 bpp colormap (needed reverse endian support in fbcon/fbmem)

Can you please elaborate? For 2.6, there should be no such problems (for 2.4,
there are).

Sorry for inexactitude, problem (as usually :)) in next (for case of
MPC5200 connected through PCI to SM501): PCI on PPC (and hence SM501) is
a little endian, PPC - big endian.
Currently (up to 2.6.13-rc6) frame buffer routines use
__raw_writeXX for write to fb memory. Result - garbage with colors in
RGB565/RGB888 modes (but pixels, meanwhile, are in place). If using
write[lw] - colors are diplayed correctly, but all image pixels are
shifted for (RGB565). This is not bug of frame buffer, this is lack of
some define in .config which tell fb/device driver how palette must be
generated (more precisely it is unknown when must be RGB565, but when
must be BGR565).

Sorry, I cannot follow.

 1. If it's a palette issue, your setcolreg() routine doesn't fill in correctly
    the pseudo palette,
 2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the offsets
    in the color bitfields in fb_var_screeninfo,
 3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
    And then there's no much we can do...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf