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


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?
>
> 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.
>

Thanks for the detailed answer.
I wanted to be sure because I would like to contribute back the code
when it becomes fully tested. It is available from SVN for testing,
but there's no documentation yet.
It was also necessary to know the right way to implement the link
between the generic FB API and NanoX/MicroWindows.

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


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