From: Carlos Munoz <carlos@kenati.com>
To: Akhilesh Soni <akhilesh@innomedia.soft.net>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Advice on Linux Framebuffer driver implemetation
Date: Thu, 05 Apr 2007 16:13:36 -0700 [thread overview]
Message-ID: <461582A0.3010403@kenati.com> (raw)
In-Reply-To: <004d01c77681$3bdbae60$0a12a8c0@innomedia>
Akhilesh Soni wrote:
> Hello,
>
> I want advice on how to proceed for the following problem
>
> As per my knowledge the *Linux frame buffer* requires the pixel data
> to be in a packed pixel *contiguous buffer*. This means that the all
> the data for one pixel must be packed together, followed by the data
> for the next pixel, etc.(please correct me if I'm wrong)
>
> On my Set-top-box hardware Vulcan (IBM ppc405), the best
> resolution supported in this packed pixel format is 8bpp color table
> format. Vulcan resolutions above the 8bpp color table resolution
> require separate luma and chroma buffers, where the hardware
> expects all the luma values to be in one buffer and all chroma values
> to be in another buffer. Since the data for the resolutions above 8bpp
> are required by the hardware to be in separate luma and chroma buffers
> it does not meet the LInux Frame buffer requirement of packed pixel data.
> Now how can I overcome this limitation where graphics H/W expects
> separate Luma and Chroma buffers whereas linux framebuffer expect all
> things packed. Is there any such driver already present which I can
> study to overcome such limitation.
Hi Akhilesh,
I would write a new frame buffer driver for your hardware that converts
RGB565 data (or whatever format is passed to the frame buffer) to
luma/chroma data. There might be some open source libraries that already
do this conversion. Writing a frame buffer driver is not very difficult.
Carlos
prev parent reply other threads:[~2007-04-05 23:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-04 6:19 Advice on Linux Framebuffer driver implemetation Akhilesh Soni
2007-04-05 23:13 ` Carlos Munoz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=461582A0.3010403@kenati.com \
--to=carlos@kenati.com \
--cc=akhilesh@innomedia.soft.net \
--cc=linuxppc-embedded@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.