The sample program ppmv_sony692 is very straight-forward.  All it does
is take each 3-consecutive bytes of the input .ppm file, representing RBG
pixels, and pack them into 5+6+5-bit words and write them into the frame
buffer.  I verified the obvious things, like the size of the .ppm file, the
size of the frame buffer (device), the mode of the acx705akm (works in
240x160-16) and the wiring between the LCD panel to the PXA255.
The fact that the penguin displays decently indicates that basic
parameters are functional.

Since I'm seeing 2 penguins overlapped vertically (note penguin image
is stored and displayed sideways rather than upright), it's likely that the
vsync parameters are off.  I've played around with the LCCR2 register,
but have not managed to "lock" the vsync properly.  Tweaking VSW
(vertical sync pulse width) doesn't seem to do much and tweaking
LPP (lines per panel) wreaks a lot of vertical havoc without getting
the proper vertical lock.  This exercise is like tweaking the vertical
hold on old TVs.

Does anyone have suggestions as to what PXA255 LCD Controller
registers might be involved in getting the vertical sync right?
Thanks for all help.

On 8/24/07, Craig Hughes < craig@gumstix.com> wrote:
On Aug 24, 2007, at 4:04 AM, Peter Lu wrote:

> My LCD is now apparently working, after adjusting some mechanical
> cabling problem and deasserting SHUTDOWN.  However, when I run:
> ppmv_sony692 sony_penguin.ppm
> I get three faint penguins somewhat overlapped and a flickering
> screen.
> I'm sure the intent of the app was to display only one penguin, which
> would probably get rid of the flickering and faintness.  The
> documentation seems to indicate that this app is customized for the
> acx705akm, so I don't know what tweaks are needed.  My understanding
> of frame buffers and LCD parameters is minimal.

The program makes strong compiled-in assumptions about the screen
resolution and bits-per-pixel depth.  It basically will attempt to
just stuff raw bits together based on these hardcoded params, and
then dump that bitstream into /dev/fb0.  If your screen is a
different x-y size or uses a different bit depth than the one the
program encodes for, then it won't work for you unless you modify
those params in the code.  iirc the x-y dimensions are #defined so
it's easy to change those, but the code basically just completely
assumes some bit-depth in terms of how the algorithm works -- I
forget if it was 8 or 16bpp.  To handle, eg, 24bpp (where maybe only
some of those 24bpp are significant, like when the PXA FB controller
is in 18bpp mode) you'll need to rewrite the algorithm to align the
bits correctly.

> I have tried both the Samsung and ALPS mode drivers and the LCD
> behaves the same way (as expected).  I think I will stick with the
> Samsung mode as the ALPS mode doesn't seem to support
> screen backlighting (by a quick look at the code).
> I'm also looking for some app or configuration to use the acx705akm
> as a simple ascii text display device.  Is setting it us as a virtual
> terminal the best bet?

Yes, using the fbcon is the easiest way to do text on an fb-backed
LCD panel.


This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>   http://get.splunk.com/
gumstix-users mailing list