This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Framebuffer support
>>>>> "tgabor" == =?ISO-8859-1?Q?G=E1bor T=F6r=F6k?= <tgabor84@gmail.com> writes:
tgabor> I have written an FB driver for a TFT with the ILI9320
tgabor> chip. This chip has a reversed RGB order, and the hardware
tgabor> can only reverse the data for writes, and can't reverse it
tgabor> for reads.
tgabor>
tgabor> Is it OK, if I mark the driver that it has a
tgabor> CYG_FB_FORMAT_16BPP_TRUE_565 pixel format? Isn't it a
tgabor> problem if it has a BGR colour order if I provide the
tgabor> appropriate cyg_fb_make_colour() and cyg_fb_break_colour()
tgabor> functions? Or should I make the hardware to reverse the
tgabor> colour order for writes and do it for reads in software?
tgabor>
tgabor> I'm wondering about this, because cyg_fb_read_block() and
tgabor> cyg_fb_write_block() provides data in and stores data from
tgabor> the native pixel format of the controller chip, which is
tgabor> BGR (5-6-5) for me. I just would like to be sure, if it
tgabor> won't cause any problems, like an application assumes RGB
tgabor> order for these buffers and bypasses cyg_fb_make_colour().
The 565 in CYG_FB_FORMAT_16BPP_TRUE_565 only indicates the number of
bits assigned to each colour. Portable higher level code should make
no assumptions about how the various colour bits are organized within
each 16-bit pixel value. Instead higher level code should always go
via the cyg_fb_make_colour() and cyg_fb_break_colour() functions or
the equivalent macros.
There are some scenarios where this is suboptimal. For example, if an
application wants to iterate through the framebuffer and manipulate
just the green channel, then manipulating the green bits directly
would be more efficient than doing a BREAK_COLOUR()/MAKE_COLOUR()
combo for each pixel - although in theory the compiler should be able
to optimize away any unnecessary shifts and masks. In practice, for
operations where performance is a big issue, application code can
always be optimized by bypassing the generic API and coding directly
for the target hardware.
So yes, your device driver should specify CYG_FB_FORMAT_16BPP_TRUE_565
and it should provide its own make_colour/break_colour() functions and
macros.
Bart
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss