QVGA for Neo

[andrzej zaborowski]

Hi,

On 27/09/2007, john cass <johnpcass at yahoo.com> wrote:
> 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?

I think you can change the framebuffer size to 240x320 but you will
need to also increase the number of dummy pixels sent by the cpu's LCD
Contoller to the LCM between the framebuffer border and the line end
(this value even has a strange name like vertical porch and horizontal
porch or something with porches) - so that the timing fits the values
configured in the LCM. I don't know which of this values fbset will
let you change.

The minimal "horizontal cycle" value in the LCM's specs is 520 clocks
and minimum "vertical cycle" is 648 lines, so even if you've only got
240 significant pixels in a line you need to arrange with fbset so
that the LCDC sends 520 or more pixels per row. I guess this means
that you won't get a better refresh rate because of lower resolution,
but instead the DMA will perform fewer RAM accesses, so stuff should
work faster.

The registers you want to change are named VFP, VBP, HFP and HBP, and
iiuc the horizontal framebuffer size + HFP + HBP sum must not change
(or be >= 520) and height + VFP + VBP sum must also not change (or
perhaps be >= 648) for the LCM to work.

>
> 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?)

I think the jbt6k74 should export these properties through sysfs as it
is a separate device from the LCDC.

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

Imho you would best have two /etc/pointercal files and you would just
swap them or you would make /etc/pointercal a symlink. There's also
some way to tell X about new calibration values without restarting.

>
> 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!

Well, I think for the LCM the only difference between VGA and QVGA is
the pixel size which is two times bigger in QVGA, although I'm only
guessing.
Regards