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