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