Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756451AbcKCJBQ (ORCPT ); Thu, 3 Nov 2016 05:01:16 -0400 Received: from up.free-electrons.com ([163.172.77.33]:60349 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755796AbcKCJBO (ORCPT ); Thu, 3 Nov 2016 05:01:14 -0400 Date: Thu, 3 Nov 2016 10:01:06 +0100 From: Maxime Ripard To: Russell King - ARM Linux Cc: Daniel Vetter , David Airlie , Thomas Petazzoni , Boris Brezillon , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Hans de Goede , Chen-Yu Tsai , Laurent Pinchart , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 0/5] drm/sun4i: Handle TV overscan Message-ID: <20161103090106.dq2bn4z7m2hzhi53@lukather> References: <20161018092422.GJ1041@n2100.armlinux.org.uk> <20161018100349.qm2f554oiwyjwrsi@lukather> <20161031084233.GS1041@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="urlknc4jzy7u3juz" Content-Disposition: inline In-Reply-To: <20161031084233.GS1041@n2100.armlinux.org.uk> User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4255 Lines: 100 --urlknc4jzy7u3juz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Russell, On Mon, Oct 31, 2016 at 08:42:34AM +0000, Russell King - ARM Linux wrote: > 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. >=20 > 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. Yes. And that is an XBMC only solution, that doesn't work with the fbdev emulation and is probably doing an additional composition to scale down and center their frames through OpenGL. We might not have a GPU in the system, and we might not even have an entire graphic stack on top either, so I don't think fixing at the user-space level is a good option (especially since we already have an overscan property in DRM). > > 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. > >=20 > > 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. >=20 > 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. I know, but on this particular hardware, composite really is just another video output. There's not even a TV receiver in it, so I don't think we have to worry about it. > > 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. >=20 > 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. I'd agree with you, but I was also told to not turn that into a generic code and deal with that in my driver. Do you have any suggestions? Thanks, Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --urlknc4jzy7u3juz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYGvzNAAoJEBx+YmzsjxAg9gAP/jbGkHCQS3J3dPb6tKfKj008 rg5dhjtn4vhDzqfEyjLhWh4rdrjuWIyf1HlBzPKcaWDLDdAq9c7ggBnstMyB/hSD nLk6S4pquSWJOcZxup8eThKJnKKgsEEGdY9QC9fA7pcIkLUnNcMXUm2pK32gUEIc C1HWbowpuD8UrH0kR99/iZt0s9BUAl5sQfPga97QsL81u2v8mnHPBMLYdHHlJAbB yBZYVjrb2CitHU7HZw1U2qn4RA6ZVwlBIKW/Gd7oQO9+M1HozOw4bw2DEMk+GTFL zd7Fa0VMZuOYzdXrJmNorr/gd8E3uX6JCfqMLn5tGQh1mQZjX/aA0QYcozP+0VVY auvRPahCcjqLgJgypx6bwfWvZFZyKnDjjKhD9yCG6HZq1Z603O8HicRmWe493qDx goQWb6PrAMFXaTj5etH585AgjShE19MUkErWRaeUrIW7l2hWHlGGww2tdtk9e3Uh DG+hWvAgw+4P9/57QyyaS2sPeuQ3qD4BwgxjMT47H6Hm2F9bj/7U8y+jRsECsUp3 Da80++uU9wTavoPneiTifaVQuCiUGz57tuqrsKgj8ovtI4jaN+ZgmbyTZZJhnB1b 8nwH7gDsKEHe0+Rht9CfhBBXVvCeM5nSVjLeXcKiB6vKvOi6SArIztYJQjYyF+fl XKwPxlLH1HE3bk2lz0sK =TLJM -----END PGP SIGNATURE----- --urlknc4jzy7u3juz--