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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.