This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]