QVGA for Neo

andrzej zaborowski balrogg at gmail.com
Fri Sep 28 13:34:43 CEST 2007

On 28/09/2007, john cass <johnpcass at yahoo.com> wrote:
> Hello Andrej - thanks for your comments regarding the LCM register setup:
> >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.
> I will make some more experiments along the lines you mention but I
> already have a feeling its more complex than this.
> I dont know what the LCM is doing when its in this 'QVGA mode' but i have
> tried several combinations of output from the LCDC which give wierd results:
> 240x320 from LCDC : the width is fine (stretched to full screen)
>                     vertically the screen is split in two and the
>                     top half of the 320 is stretched and repeated
>                     in both (i think this is actually two frames
>                     one in the top half another in the bottom)
> 240x640 from LCDC : the width is fine (stretched to full screen)
>                     vertically we see the top half of the console
>                     stretched over the whole screen (320>640)
>                     when running mplayer, its as if the whole
>                     640 vertical pixels are displayed correctly
>                     (no vertical stretching)
> 480x320 from LCDC : this shows 'perfectly', width stretched across
>                     whole screen, height perfect.  Of course
>                     there is the right half of the frame buffer
>                     which is not visible but is assumed to be
>                     visible by fbcon etc.
> 480x640 from LCDC : this shows 'perfectly', width strecthed across
>                     whole screen, height perfect.  In this case
>                     the top left quadrant of the framebuffer
>                     is shown in qvga - the other 3 quadrants
>                     are invisible but still assumed to be there
>                     by fbcon, mplayer, X etc.
> I'll check further regarding the porch timings - all these
> experiments were carried out without changing those timings,
> just the data display.
> But note: setting the LCDC to output something 'wierd' like
> 360x360 results in strange effects on the display - so somehow
> it much know its being given 'valid pixels' rather than
> 'dead space' like the porches...
> I think it might be counting valid pixels or something, i dont
> think it is just relying on where hsync and vsync happen.

Well, right, there are 4 lines between the LCDC and the LCM that are:
VS - vertical sync, CLK - the pixel clock, DE - high when the pixel is
valid (i.e. should be displayed) and HS - horiz sync. (Plus of course
the pixel data, 18 lines)

More information about the neo1973-hardware mailing list