Re: [RFC 2.6.26-rc9 1/5] pxafb: add shared framebuffer interface

On Tue, Jul 29, 2008 at 10:41 PM, Eric Miao [off-list ref] wrote:

On Sat, Jul 26, 2008 at 11:30 AM, Jaya Kumar [off-list ref] wrote:

quoted

I took a look at doing the above, ie: adjusting bpp instead of
custom_xfer_size. I've realized that I would still need to adjust lccr
in at least one other place:

       fbi->reg_lccr1 =
               LCCR1_DisWdth(var->xres) +

I'll try to improve my explanation. :-)

The reason for this is that metronome requires a different bus width
(16 bit) for AMLCD transfers than it requires for its expected bits
per pixel ( 8 bits). To get LCDC to use 16 bits on the AMLCD bus, we
need to set 16bpp in LCCR3. So we then need to divide down the x
resolution in LCCR1. Eg: 800 pixels at 8bpp is the framebuffer. We
need 16-bit transfers so we set the desired pixels per line in LCCR to
= 800 pixels / ( 16 custom bus bits / 8 bits per pixel ) = 400 pixels
per line. So the code would be like:

pix_per_line = var->xres / ( inf->custom_lccr_bpp / var->bits_per_pixel )

I hope I was able to explain my reasoning for this above.

Sorry for the delay, I begin to understand the way this metronome is
working, so each transfer is 16-bit wide and contains two 8-bit pixels?

Correct, the AMLCD xfer is 16-bit wide and is treated by Metronome as
2 8-bit pixels.

Then the most simple way is to treat this display as 16-bit, and
adjust the resolution parameters in the platform data with a nice
comment.

I originally had it as .bpp = 16 ( in v6 and before) and used
custom_xfer_data to divide down the buffer sizes. The resolution needs
to stay at 800x600 so that the reported resolution for the display is
correct. So've I changed that to .bpp = 8 and used custom_lccr_bpp to
set LCCR3 to 16bpp in v7. Let me know if the implementation in v7 is
consistent with your suggestion.

The problem of doing so is that:
1) framebuffer console cann't work anymore, and will show garbage
instead of showing the nice penguine logo

2) the framebuffer application has to be aware of this, and handles
the pixel format correctly.

Provided the fact of this weird organized pixel format, I don't see many
chances that X window or console can be run on top of this, but a
specialized application, no?

Deferred IO converts the pixel data organization for the Metronome
controller so the latter is transparent to anything above fbdev. I
have tested with Xfbdev and it works quite well. So no specialized
applications needed. :-) Some video clips of it running here:
http://youtube.com/watch?v=Or3R3Q8oyuE and also a LinuxJournal article
showing the display with dillo and other standard applications.
http://www.linuxjournal.com/article/10110

Thanks,
jaya

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/