From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] drm/sun4i: Handle TV overscan
Date: Tue, 18 Oct 2016 10:24:22 +0100 [thread overview]
Message-ID: <20161018092422.GJ1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <cover.bb9be34c7fd7767e31823f78a15ae1c127293c34.1476779323.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 18, 2016 at 10:29:33AM +0200, Maxime Ripard wrote:
> The Allwinner display engine doesn't have any kind of hardware help to deal
> with TV overscan.
I'm not sure I follow. My understanding (from reading the CEA specs)
is that TVs are expected to overscan the image, so the upper left, and
bottom right pixels are not visible.
I assume we are talking about TVs connected via HDMI. In the HDMI AVI
infoframe, there are bits which specify whether the image should be
overscanned or underscanned - however, whether a TV implements those
bits is rather sketchy. I assume when you say "any kind of hardware
help" you mean you can't control these bits?
However, some (most?) TVs now implement a menu option which allows the
(over)scan mode to be selected. Others assume that if it's a TV mode,
it's supposed to be overscanned, if it's a "PC" mode, it should be
underscanned and provide no option to change the behaviour.
> This means that if we use the only mode the hardware provides (either PAL
> or NTSC, or something else), most of the screens will crop the borders of
> the image, which is bad.
I think you're trying to apply monitor-type behaviour to TVs...
> We can however use somekind of a hack, to instead reduce the mode exposed
> to the userspace, and center it in the final image. We would expose
> different overscan ratio to be able to deal with most of the screens, each
> reducing more the displayable area.
I'm not sure we need "a hack". What if we treated the primary plane just
like any other (eg, overlay) plane? We could then specify (eg) a 1920x1080
display mode, but with the primary plane reduced in size, positioned in
the centre of the display mode?
I know that there's hardware out there which can do exactly that - Marvell
Dove implements this: you set the display size separately from two planes,
one graphics plane and one video plane. Both planes can be positioned
anywhere in the displayed size.
We could then specify at DRM level that a connected device overscans by
N%, and have the primary plane adjusted by DRM itself.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2016-10-18 9:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 8:29 [PATCH 0/5] drm/sun4i: Handle TV overscan Maxime Ripard
2016-10-18 8:29 ` [PATCH 1/5] drm/modes: Rewrite the command line parser Maxime Ripard
2016-11-16 17:12 ` Sean Paul
2016-11-21 7:36 ` Maxime Ripard
2016-10-18 8:29 ` [PATCH 2/5] drm/modes: Support modes names on the command line Maxime Ripard
2016-11-16 17:21 ` Sean Paul
2016-11-21 7:40 ` Maxime Ripard
2016-10-18 8:29 ` [PATCH 3/5] drm/sun4i: Add custom crtc state Maxime Ripard
2016-10-18 8:29 ` [PATCH 4/5] drm/sun4i: Compute TCON1 mode from tv mode Maxime Ripard
2016-10-18 8:29 ` [PATCH 5/5] drm/sun4i: Add support for the overscan profiles Maxime Ripard
2016-11-08 8:59 ` Daniel Vetter
2016-11-10 14:56 ` Maxime Ripard
2016-11-11 9:17 ` Daniel Vetter
2016-11-21 7:30 ` Maxime Ripard
2016-10-18 9:24 ` Russell King - ARM Linux [this message]
2016-10-18 10:03 ` [PATCH 0/5] drm/sun4i: Handle TV overscan Maxime Ripard
2016-10-18 17:57 ` Jean-Francois Moine
2016-10-31 8:42 ` Russell King - ARM Linux
2016-11-03 9:01 ` Maxime Ripard
2016-11-03 9:54 ` Russell King - ARM Linux
2016-11-07 15:09 ` Maxime Ripard
2016-11-07 15:46 ` Russell King - ARM Linux
2016-11-10 14:25 ` Maxime Ripard
2016-11-03 21:11 ` Sean Paul
2016-11-07 14:11 ` Maxime Ripard
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=20161018092422.GJ1041@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).