Content-Type: multipart/alternative; boundary="----=_NextPart_001_008E_01C7E96F.7F3AA560" ------=_NextPart_001_008E_01C7E96F.7F3AA560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Peter, Here's the /etc/init.d script I use to initialize my SONY ACX705AKM. Using these values I have undistorted ppm graphics when sent to /dev/fb0 and undistorted text when sent to /dev/tty0. Regards, John Alfredo _____ From: gumstix-users-bounces@lists.sourceforge.net [mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf Of Peter Lu Sent: Monday, August 27, 2007 12:58 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] Sony Acx705akm LCD display Hi, 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. C ------------------------------------------------------------------------- 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 gumstix-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gumstix-users ------=_NextPart_001_008E_01C7E96F.7F3AA560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Peter,

 

Here’s the /etc/init.d script = I use to initialize my SONY ACX705AKM.  Using these values I have = undistorted ppm graphics when sent to /dev/fb0 and undistorted text when sent to = /dev/tty0.

 

Regards,

 

John Alfredo

 


From: gumstix-users-bounces@lists.sourceforge.net [mailto:gumstix-users-bounces@lists.sourceforge.net] On Behalf Of Peter Lu
Sent: Monday, August 27, = 2007 12:58 PM
To: General mailing list for gumstix users.
Subject: Re: = [Gumstix-users] Sony Acx705akm LCD display

 

Hi,

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.

C

-------------------------------------------------------------------------=
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
gumstix-users@lists.s= ourceforge.net
https= ://lists.sourceforge.net/lists/listinfo/gumstix-users

 

------=_NextPart_001_008E_01C7E96F.7F3AA560--