public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Andre Heider <a.heider@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] video: bcm2835: fix various output modes
Date: Wed, 23 Oct 2013 22:06:02 +0200	[thread overview]
Message-ID: <20131023200602.GB29233@gmail.com> (raw)
In-Reply-To: <52680011.4070005@wwwdotorg.org>

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

  reply	other threads:[~2013-10-23 20:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 20:27 [U-Boot] [PATCH 2/2] video: bcm2835: fix various output modes Andre Heider
2013-10-23 16:57 ` Stephen Warren
2013-10-23 20:06   ` Andre Heider [this message]
2013-10-24 18:14   ` Andre Heider
2013-10-24 22:08     ` Stephen Warren
2013-10-24 18:00 ` [U-Boot] [PATCH v2 2/2] video: bcm2835: respect the pitch value Andre Heider
2013-10-24 22:13   ` Stephen Warren
2013-11-07 23:04   ` Anatolij Gustschin
2013-11-09 10:00   ` [U-Boot] [PATCH] lcd: allow overriding lcd_get_size() Anatolij Gustschin
2013-11-12  8:44     ` Anatolij Gustschin
2013-11-09 10:07   ` [U-Boot] [PATCH v3 2/2] video: bcm2835: respect the pitch value Anatolij Gustschin
2013-11-09 12:25     ` Andre Heider
2013-11-12  8:39       ` Anatolij Gustschin
2013-11-11 16:45     ` Stephen Warren
2013-11-12  8:48     ` Anatolij Gustschin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131023200602.GB29233@gmail.com \
    --to=a.heider@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox