Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758341AbcJRJYv (ORCPT ); Tue, 18 Oct 2016 05:24:51 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:44838 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753089AbcJRJYm (ORCPT ); Tue, 18 Oct 2016 05:24:42 -0400 Date: Tue, 18 Oct 2016 10:24:22 +0100 From: Russell King - ARM Linux To: Maxime Ripard 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: <20161018092422.GJ1041@n2100.armlinux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2246 Lines: 47 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.