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
next prev parent 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