nanogui: nano-X on PXA270 in 18bpp mode
Subject:
Done: [nanogui] nano-X on PXA270 in 18bpp mode
From:
BRACH Vincent ####@####.####
Date:
31 May 2007 15:43:08 +0100
Message-Id: <1180622545.5521.91.camel@hostname.domainname>
Hi all and Greg,
:: Ever heard of a 18bpp patch ?
:
:Not yet!
:
:: If i decide to go into nano-X source code and add this mode, is it a
big
:: work ?
:
:Not necessarily. There are macros in include/device.h and/or
:include/mwtypes.h that will allow conversion from and
:to RGB and PIXELVALs. The bigger issue will be the
:screen driver mods - you'll have to store the pixel values
:unpacked in 3 bytes, and then how exactly will you write
:the framebuffer memory as 18bpp? In other words,
:what is the 18bpp framebuffer color memory structure?
:
:Regards,
:Greg
I answer to this mail because I'm the colleague of françois who post the
first mail about this subject. We work together at the same company and
I currently develop a MMI with nano-X for this hardware with a PXA270
base CPU target.
I solved the problem while developing a "18bpp Linear Video Driver for
Microwindows" fblin18.c based on the fblin24.c with rights adaptations
for the framebuffer color memory structure of the PXA270 (I imagine that
it work well on PXA210 and PXA250, but I'm not sure about the
framebuffer color memory structure and bpp available modes)
The target we use is a PX270 with a 18bits pinout colors LCD panel.
The PXA270 accept 8bpp framebuffer to drive 18bits LCD panel, 18bpp
framebuffer to drive the same panel, but the 16bpp framebuffer mode is
not available to drive 18bits LCD panel. Only 16bits LCD panel are
supported to work with 16bpp framebuffer (It's the reason we could'nt
set linux framebuffer in 16bpp mode).
I wish to provide my work about 18bpp driver for microwindows for
nano-x/microwindows users and developpers community.
I did this work with the "microwindows-0.91" based tarball
(microwindows-full-0.91.tar.gz).
The differences between the originale (v0.91) and my actually
microwindows sources are only affect the following files :
- drivers/fb.c (check and choose the right linear driver for 18bpp)
(state=modify)
- drivers/fblin18.c (based on the fblin24.c with rights adaptations for
18bpp) (state=add)
- drivers/Objects.rules (add the fblin18.o object to compil)
(state=modify)
- drivers/scr_fb.c (add the 18bpp mode to select right 'psd->pixtype'
MWPF_TRUECOLOR888) (state=modify)
- include/device.h (only a comment modification) (state=modify)
- engine/devdraw.c & engine/devopen.c (right 18bpp switch/case - but I
don't know if it is really necessary)
Let me know if you are interested about this work for futur releases and
which format (patch / tarball / others) can I send to you ?
Another thing :
We use the nano-X in 'MWPORTRAIT_RIGHT' regarding the LCD panel
disposition. I noticed a very long time of displaying in this portrait
mode (to draw a complete page 480x640 in bgcolor white for exemple)
compared to the standard (MWPORTRAIT_NONE) portrait mode and I don't
understand why ? I don't understand where is the problem.
Any ideas about this problem ?
Thanks for help,
Vincent
