QVGA for Neo

john cass johnpcass at yahoo.com
Thu Sep 27 15:42:47 CEST 2007


I have been playing with QVGA mode for the Neo and have some observations and 
questions. QVGA will be important for several key Neo applications including 
games and movie playing.  It may also offer lower power usage.

The LCM register set is not documented but a patch was made by Stefan Schmidt 
which demonstrated switching it into QVGA mode.(patch for /drivers/spi/jbt6k74.c)
Basically this patch changes two register values called DISPLAY_MODE and 
QUAD_RATE, it also fills in timing values to an alternate set of registers 
for vga or qvga.

This patch does not change the framebuffer driver (within the s3c2410 - 
/drivers/video/s3c2410fb.c) which by default is set up to always generate a 
VGA signal.

When I change mode to qvga with Stefan's patch, the screen does switch to a 
240x320 resolution and the 'top-left' of the original VGA screen is shown on 
the display.  There is quite some noise in the  image and the brightness is 
higher - I find that if I alter the pixelclock for the framebuffer
VGA signal from 33.25MHz to 16.625Mhz (using fbset -pixclock 60155) this 
effect is eliminated and you end with a farily good QVGA display.
Its very crisp with text.  I can play movies using mplayer -vo fbdev - 
if you have recompressed the movie with mencoder to rotate the image and 
scale to 240x320 and a bitrate of about 256 it works almost perfectly.  
There is a small sense of horizontal lines on the image that looks a little 
like poor interlacing.

So far so good but in order to make it usable, there are some problems:

1) Does qvga mode in the LCM require/expect a vga signal, or can it run from a 
    qvga signal?  Are different setting required to the LCM to let it know what 
    its getting?
    As it stands, we can see qvga on the screen but linux (console, X)  still 
    thinks it has a 480x640 framebuffer (which it does!) and I cant see a way 
    of forcing it to use only a part of that.
    It is relatively straightforward to change the framebuffer (and console, X) to
    generate a qvga signal using fbset but will the LCM accept that?

2) What's the best way to send a command from the framebuffer driver to the LCM 
    (spi) module - so that we can have a full change of mode using the
    framebuffer's ioctl (e.g. via fbset)?
    The way the code is currently structured, a call to the mode change function
    in the LCM module needs a data structure which the framebuffer doesnt know 
    about. (e.g. should we store a reference to the jbt_info structure 
    statically in jbt6k74.c so that external callers dont need to specify  it?
    or should we try to arrange a call through the sysfs user interface?)

2a)    We would also need to 'recalibrate' the touchscreen when changing video mode 
    - should this be under control of fbset and/or within X?

3) There is a problem when setting the pixclock using fbset in that it causes 
    the console to freeze - it looks like only the top line of the console is 
    working    and when running mplayer from this console, only the top line (y=0)
    is shown.  If I run the fbset -pixclock command while X is displaying then 
    kill X (console takes over) it works fine.    I am trying to track this 
    problem - its somewhere in fbcon.c to do with a call to fbcon_modechanged()
    I think...

I would appreciate any extra knowledge there is on the  LCM register set and 
how it expects to receive and use qvga data!


Catch up on fall's hot new shows on Yahoo! TV.  Watch previews, get listings, and more!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/neo1973-hardware/attachments/20070927/fbfaff62/attachment.html

More information about the neo1973-hardware mailing list