This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Framebuffer support
- From: "Gábor Török" <tgabor84 at gmail dot com>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Sun, 16 Nov 2008 16:03:03 +0100
- Subject: [ECOS] Framebuffer support
Hi!
I have written an FB driver for a TFT with the ILI9320 chip. This chip
has a reversed RGB order, and the hardware can only reverse the data
for writes, and can't reverse it for reads.
Is it OK, if I mark the driver that it has a
CYG_FB_FORMAT_16BPP_TRUE_565 pixel format? Isn't it a problem if it
has a BGR colour order if I provide the appropriate
cyg_fb_make_colour() and cyg_fb_break_colour() functions? Or should I
make the hardware to reverse the colour order for writes and do it for
reads in software?
I'm wondering about this, because cyg_fb_read_block() and
cyg_fb_write_block() provides data in and stores data from the native
pixel format of the controller chip, which is BGR (5-6-5) for me. I
just would like to be sure, if it won't cause any problems, like an
application assumes RGB order for these buffers and bypasses
cyg_fb_make_colour().
Gábor
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss