Sorry for this late though about lcd issues.
lcd_color_fg : lcd_color_bg;
*d++ = (bits & 0x80) ? 0xffff : 0;
Here my patch uses hardwired 0 and ~0 for 16-bit pixels. Anatolij suggested to use lcd_color_fg and lcd_color_bg as in the original code, but unfortunately it doesn't work.
lcd_color_fg is set by common/lcd.c itself, using this function:
static void lcd_setfgcolor (int color) { #ifdef CONFIG_ATMEL_LCD lcd_color_fg = color; #else lcd_color_fg = color & 0x0F; #endif }
So, however white I declare my color, it turns out blue. While I'd understand a difference based on LCD_COLOR8 and LCD_COLOR16 (but even in that case I'd request the caller to do the right thing avoiding this late "fix"), I really can't tell why the atmel display is different from other ones.
It's true that I can force lcd_color_fg to whatever I want, but only after lcd_clear() is called. Moreover, if there's centralized I wouldn't cowardly change it behind it's back.
This is one of the reasons why my original post was an RFC. common/lcd.c is quite a mess and touching it is difficult.
At this point I still think forcing 0xffff and 0, ignoring lcd_color_fg, is the right thing to do at least until atmel specifics are removed from common/lcd.c.
BTW: I have a 9263ek an a 9261ek, so I might be able to try to propose an atmel-related cleanup in the future, but not on short term, unfortunately.
/alessandro