QVGA mode for Neo
johnpcass at yahoo.com
Thu Sep 27 15:32:17 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
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
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 would appreciate any extra knowledge there is on the LCM register set and
how it expects to receive and use qvga data!
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the neo1973-hardware