[U-Boot] [PATCH 2/2] video: bcm2835: fix various output modes

Andre Heider a.heider at gmail.com
Wed Oct 23 22:06:02 CEST 2013


On Wed, Oct 23, 2013 at 05:57:53PM +0100, Stephen Warren wrote:
> On 10/22/2013 09:27 PM, Andre Heider wrote:
> > Depending on the firmware's video options [1] the active SDTV or
> > HDTV mode can yield a framebuffer with noncontiguous horizontal lines,
> > giving a messed up display, for both, u-boot and the loaded kernel.
> > 
> > To always archive the required contiguousness for the used 16bpp, round
> > the framebuffer width down so its aligned to a width of 16.
> 
> This doesn't sound like the correct approach. By doing this, either the
> SET_PHYSICAL_W_H request will fail since the requested mode doesn't
> match the connected display device, or perhaps it'll work, but end up
> with a frame-buffer that's a different resolution than the video signal,
> so the HW will scale the image slightly, which will reduce quality.

SET_PHYSICAL_W_H works in any case, but yeah, it does get "funky"
resolutions in some cases.

The thing is, the firmware is stupid to begin with (duh). In my case, I do
have both outputs connected. For the analog one, I have to set sdtv_*
and overscan_* config settings.
When the HDMI connection is active, the analog output is inactive, but
yet the firmware applies the sdtv_* and overscan_* settings to the HDMI
output too, so the clean 1:1 resolution is already gone...

> Instead, can't you obtain the buffer width and stride separately, and
> then configure the LCD core based on both those values, rather than
> assuming they're the same?

What I did try is to get the overscan values and add those to the
requested resolution (that's where patch 1 comes from). That gives saner
resolutions, but some are still broken for me.

I agree that getting the pitch value would be the right thing to do, I
do some digging to find a spot where to shove that into.

Thanks,
Andre


More information about the U-Boot mailing list