Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933722AbcKJOZY (ORCPT ); Thu, 10 Nov 2016 09:25:24 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:59501 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933408AbcKJOZW (ORCPT ); Thu, 10 Nov 2016 09:25:22 -0500 Date: Thu, 10 Nov 2016 15:25:07 +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: <20161110142507.hxf25hm6x5wijv5q@lukather> References: <20161018092422.GJ1041@n2100.armlinux.org.uk> <20161018100349.qm2f554oiwyjwrsi@lukather> <20161031084233.GS1041@n2100.armlinux.org.uk> <20161103090106.dq2bn4z7m2hzhi53@lukather> <20161103095444.GX1041@n2100.armlinux.org.uk> <20161107150909.rcte56amjkmd6mhx@lukather> <20161107154652.GH1041@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4jiukrp4wsdjgdl3" Content-Disposition: inline In-Reply-To: <20161107154652.GH1041@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: 5346 Lines: 123 --4jiukrp4wsdjgdl3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 07, 2016 at 03:46:52PM +0000, Russell King - ARM Linux wrote: > On Mon, Nov 07, 2016 at 04:09:09PM +0100, Maxime Ripard wrote: > > Hi Russell, > >=20 > > On Thu, Nov 03, 2016 at 09:54:45AM +0000, Russell King - ARM Linux wrot= e: > > > > 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. > > >=20 > > > Well, it will have to be doing a scaling step anyway. If the video > > > frame is a different size to the active area, scaling is required > > > no matter what. A 576p SD image needs to be scaled up, and a 1080p > > > image would need to be scaled down for a 1080p overscanned display > > > with a reduced active area to counter the overscanning - no matter > > > how you do it. > >=20 > > Yes, except that scaling is not always an option. In my particular > > example, there's no scaler after the CRTC, which essentially prevents > > it from being used in that use case. Which is also why I ended up > > reducing the mode reported to the user. >=20 > I think you completely missed my point. Let me try again. >=20 > If you expose a reduced mode to the user, you are reporting that (eg) > the 1080p-timings mode does not have 1920 pixels horizontally, and > 1080 lines. You are instead reporting that it has (eg) 1800 pixels > horizontally and maybe 1000 lines. >=20 > So, when you play back a 1080 video, you are going to have to either: >=20 > 1. crop the extra 120 pixels horizontally and 80 lines vertically > or > 2. scale the image. >=20 > However, this is a completely independent issue to how we go about > setting a video mode that is 1800x1000 in the first place. >=20 > What you're suggesting is that we add code to the kernel to report that > your non-EDID, analogue output transforms the standard 1920x1080 timings > such that it has a 1800x1000 active area. >=20 > I'm suggesting instead that you can do the same thing in userspace by > specifically adding a mode which has the 1920x1080 standard timings, > but with the porches increased and the active area reduced - in exactly > the same way that you'd have to do within the kernel to report your > active-area-reduced 1800x1000 mode. Ah, yes, you meant input scaling, not output, sorry. > > > For graphics, userspace could add mode(s) with increased porches and > > > reduced active area itself to achieve an underscanned display on a > > > timing which the display device always overscans - there's no need to > > > do that in the kernel, all the APIs are there to be able to do it > > > already. > > >=20 > > > That means your framebuffer will be smaller, but that's the case > > > anyway. > >=20 > > Yes, that would be a good idea. But it's not always an option for > > applications that would rely on the fbdev emulation (like QT's eglfs), > > which would then have no way to change whatever default there is (and > > the only one able to know how bad it actually is is the user). >=20 > I guess this is the problem with DRM people wanting to deprecate fbdev... > too much stuff currently relies upon it, but DRM on x86 has always had > the reduced functionality. >=20 > I guess there's two solutions here: >=20 > 1. Either DRMs fbdev gains increased functionality, or > 2. The fbdev-only applications/libraries need to be ported over to > support DRM natively. >=20 > This has been a bar for some time to moving over to DRM, and I've heard > very little desire on either side to find some sort of compromise on the > issue, so I guess things are rather stuck where they are. I guess it really all boils down to this, and whether the userspace will be able to set a custom mode on its own. "Advanced" stacks like Xorg and Wayland will, but simpler and / or legacy applications will depend on the fbdev emulation, either because they've not been converted through DRM (like you suggested) or because it depends on a blob that requires it (and then you're stuck). And since the kernel already deals with overscan through a generic property, it really feels like it's the place it should be done to address all needs (and ideally in a generic way). Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --4jiukrp4wsdjgdl3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYJIM+AAoJEBx+YmzsjxAgoJoP/38s+mEY9OUOyZQoPo8KjzsB HlrEW5XtqHoEcoW6fs/a8uwnVad6/Q2i0OcCT1Cfo4M6SQZaRbDdP1QSdnPQ83XE XwsXTrll0WN+kHPREb1/Zmus3b8e4fuS27W1Fp+JrvDPLn9hBSOiiK59/mMB0m1s mRRyPiY3uOPq256iYxMmKALXXoS9tjB5yz0kQ/XP+q1nLTH0KslyLhbvYtpbZ3nM JMmN0cQ1Lnu50aUt7LZIurhCccRE8WIYBUt9TT784YKz3DYjU/cbIlSEAe3JlMwO nCGIYt++PdroPY9B5rzKMxC96lKU3aBrKSWaYH93a1EW8SfHmeRQzk6Yx8Q99xY+ AQ9AsBR/xEh6GL6JMeNnDoIAg61GSJ0rF1+8HexAsPtHHFahSWGr2eH+wjZvf7kU W3Jg6w/RVX29lmJkAx4omfLcWNbd4yNb0CNi6swdfuuLtXaupEiG1WI5dqgQZuOX 0FX3bgmMX+VzL9UoCxFP3ZSOXHUu6IKrZZeGla68RcmdQdy5U+8BE4duAR3bjvfq Hao566NkoTatNvhCEqD0FPpYdkhkGJzOV8EX9QRpFAV1FUu2xRLWiZPWqON6DHU2 ws4wPYFi6N1zMn1J9rlp6aclcz4ZlbZllvSk1r53Tcsr4XkLcbz3WtbgCFGCAFAh KZA504Q7+tPnH5NXy91w =nrdP -----END PGP SIGNATURE----- --4jiukrp4wsdjgdl3--