Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757950AbcJRKEJ (ORCPT ); Tue, 18 Oct 2016 06:04:09 -0400 Received: from up.free-electrons.com ([163.172.77.33]:55215 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755283AbcJRKEB (ORCPT ); Tue, 18 Oct 2016 06:04:01 -0400 Date: Tue, 18 Oct 2016 12:03:49 +0200 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: <20161018100349.qm2f554oiwyjwrsi@lukather> References: <20161018092422.GJ1041@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ttmabpsis4rh2omd" Content-Disposition: inline In-Reply-To: <20161018092422.GJ1041@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: 5193 Lines: 126 --ttmabpsis4rh2omd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Russell, On Tue, Oct 18, 2016 at 10:24:22AM +0100, Russell King - ARM Linux wrote: > 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. >=20 > 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. Yes, this is why we have to work around it somehow. > 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? >=20 > 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. We're talking about plain dumb composite output, so no infoframes, setup or anything here :) > > This means that if we use the only mode the hardware provides (either P= AL > > or NTSC, or something else), most of the screens will crop the borders = of > > the image, which is bad. >=20 > I think you're trying to apply monitor-type behaviour to TVs... Yes, kind of. Our users are usually running a desktop distro, and the default output on those boards are just plain composite, which means running any DE onto a TV. Note that it's not only about the interface itself, but you'll lose content for all pictures displayed. And no one cares about the TV safe area anymore these days (starting with the framebuffer console). > > 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. >=20 > 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 1920x10= 80 > display mode, but with the primary plane reduced in size, positioned in > the centre of the display mode? >=20 > 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. This might have been poorly worded on my side, but it's exactly what I'm doing in those patches. > We could then specify at DRM level that a connected device overscans by > N%, and have the primary plane adjusted by DRM itself. I'd agree with you, however, there's a few issues with that I think. 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. 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. 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. Thanks, Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --ttmabpsis4rh2omd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYBfN/AAoJEBx+YmzsjxAgkpQP/AocIDXBZG1pmDFhkB95g2jr sbq9o9cS9LoHwRP7RNKFX+2z+NUL64Ot86jyKpxpXi0DiNEeSmfTgd8RrglVPwE3 Onq9mK/wgb3xY655/DuUR3SG2bUMlj6A/VRmvsMdN5hc7/4eLu+Ze998TJ5R6jFu sQ9EkGnBL+S69QrBHwySGzKoXoN78AMBYLSo4tyM3nUzdZC+AzsUzeF+yCQj75s0 QOiCx4SIcdrqpV6TVhYNGifuPDT02Be4Port79hwRtRnz4xRw0UzqnSAa/ZlyHKV hP1uLopFKcnszhK+5mOc2ddKE2dCwBrosv92jZYDUpn3Jjggow3qqlfNtbNTMfov YlK7K5BcAPeKo11edQCGss/FSM9qsd2QdVb6/cSU2zVjwBoDtbIXQ3DulT4HEOAH YR5G3oxika/8BDDFLIGiwgxySnMRzUcUfOpBTBEYCiHE0u47p8amqLbgOnhect7v hx3kKN8TufO/Axbd9ahcFZA+glwDCPj8lwu09+i3NNxfNeXottzIk8Ry249wrSSu wVJt/mN0hY+66qdncJBMYaWhA3vP+Bbk8KOF4UrKJdLHi4D+/Gx6A0lRugu/sgEc 7p/2Mj6CZtwCXawsdMt1htxY+z7JB0qfuB0pXhhF5lGhYsaBEZvfuXr2qQi/hKGq dN0uy4DUNjcXZLgbywN7 =26Ka -----END PGP SIGNATURE----- --ttmabpsis4rh2omd--