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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot