linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 31 Oct 2016 08:42:34 +0000	[thread overview]
Message-ID: <20161031084233.GS1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20161018100349.qm2f554oiwyjwrsi@lukather>

On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> The first one is that this overscanning should be reported by the
> connector I guess? but this is really TV specific, so we need one way
> to let the user tell how the image is displayed on its side, and we
> cannot really autodetect it, and this needs to be done at runtime so
> that we can present some shiny interface to let it select which
> overscan ratio works for him/her.

See xbmc... they go through a nice shiny setup which includes adjusting
the visible area.  From what I remember, it has pointers on each corner
which you can adjust to be just visible on the screen, so xbmc knows
how much overscan there is, and xbmc itself reduces down to the user
set size.

> The second one is that we still need to expose the reduced modes to
> userspace, and not only the displayed size, so that the applications
> know what they must draw on. But I guess this could be adjusted by the
> core too.
> 
> In order to work consistently, I think all planes should be adjusted
> that way, so that relative coordinates are from the primary plane
> origin, and not the display origin. But that could be adjusted too by
> the core I guess.

I'm not sure about that - we want the graphics to be visible, but that
may not be appropriate for an video overlay frame.  It's quite common
for (eg) broadcast video to contain dead pixels or other artifacts on
the right hand side, and the broadcast video expects overscan to be
present.

I know this because I have run my TV with overscan disabled, even for
broadcast TV.

> The fourth one being the major one. Every time I raised the issue on
> IRC, the answer basically was "we don't care about analog", so I'm a
> bit pessimistic about whether dealing with this in the core would be
> accepted, hence why I chose to deal with this at the driver level.

Yea, that's quite sad, "analog" has become a dirty word, but really
this has nothing to do with "analog" at all - there are LCD TVs (and
some monitors) out there which take HDMI signals but refuse to
disable overscan no matter what you do to them if you provide them
with a "broadcast"  mode - so the analog excuse is very poor.

-- 
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.

  parent reply	other threads:[~2016-10-31  8:42 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 ` [PATCH 0/5] drm/sun4i: Handle TV overscan Russell King - ARM Linux
2016-10-18 10:03   ` Maxime Ripard
2016-10-18 17:57     ` Jean-Francois Moine
2016-10-31  8:42     ` Russell King - ARM Linux [this message]
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=20161031084233.GS1041@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).