[ECOS] Framebuffer support and MicroWindows

["Gábor Török" <tgabor84 at gmail dot com>]

On Tue, Nov 18, 2008 at 1:03 AM, Bart Veer <bartv@ecoscentric.com> wrote:
>>>>>> "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.

I've came across this section in the framebuffer docs:
http://www.ecoscentric.com/ecospro/doc.cgi/html/ecospro-ref/framebuf-colour.html#FRAMEBUF-COLOUR-FORMATS
It fixes the bit layout of the various pixel formats. Then what should
I do? Can higher layers rely on this or not?

---------- The text below refers to the case when I can't depend on
the arrangement of colour bits ----------

I had a look into the various drivers for MicroWindows, and the code
of the drawing engine. If MicroWindows can't depend on the arrangement
of colour bits in a pixel, then I must present truecolour eCos
framebuffers as MicroWindows formats
MWPF_TRUECOLOR0888	/* pixel is packed 32 bits 8/8/8 truecolor*/ or
MWPF_TRUECOLOR888	/* pixel is packed 24 bits 8/8/8 truecolor*/
and depend on the BREAK_COLOUR()/MAKE_COLOUR() macros. I think it has
no remarkable performance impact, because images are also converted to
an internal 32 bit ABGR format before rendering.

But for paletted devices:
CYG_FB_FORMAT_1BPP_MONO_0_BLACK
CYG_FB_FORMAT_1BPP_MONO_0_WHITE
CYG_FB_FORMAT_1BPP_PAL888
CYG_FB_FORMAT_2BPP_GREYSCALE_0_BLACK
CYG_FB_FORMAT_2BPP_GREYSCALE_0_WHITE
CYG_FB_FORMAT_2BPP_PAL888
CYG_FB_FORMAT_4BPP_GREYSCALE_0_BLACK
CYG_FB_FORMAT_4BPP_GREYSCALE_0_WHITE
CYG_FB_FORMAT_4BPP_PAL888
CYG_FB_FORMAT_8BPP_PAL888
it would be better to use the colour management of MicroWindows with
MWPF_PALETTE pixel format. Then MW would be aware that it works with a
paletted device and adjust things accordingly.
There is a big question for me regarding paletted eCos framebuffer
devices: should BREAK_COLOUR()/MAKE_COLOUR() be used, when working
with the palette entries?

I welcome any comments on this.

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