From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 408C5C388F7 for ; Tue, 10 Nov 2020 08:57:06 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3A7C32080A for ; Tue, 10 Nov 2020 08:57:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A7C32080A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ravnborg.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C4A41895B9; Tue, 10 Nov 2020 08:57:03 +0000 (UTC) Received: from asavdk3.altibox.net (asavdk3.altibox.net [109.247.116.14]) by gabe.freedesktop.org (Postfix) with ESMTPS id D8C92895B9 for ; Tue, 10 Nov 2020 08:57:02 +0000 (UTC) Received: from ravnborg.org (unknown [188.228.123.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk3.altibox.net (Postfix) with ESMTPS id 09C9F20038; Tue, 10 Nov 2020 09:56:59 +0100 (CET) Date: Tue, 10 Nov 2020 09:56:58 +0100 From: Sam Ravnborg To: Paul Cercueil Subject: Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of?? the screen Message-ID: <20201110085658.GA2027451@ravnborg.org> References: <20201105083905.8780-1-paul@crapouillou.net> <20201107193311.GB1039949@ravnborg.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=VbvZwmh9 c=1 sm=1 tr=0 a=S6zTFyMACwkrwXSdXUNehg==:117 a=S6zTFyMACwkrwXSdXUNehg==:17 a=8nJEP1OIZ-IA:10 a=7gkXJVJtAAAA:8 a=ER_8r6IbAAAA:8 a=9CIfjzEbJXW8LZeqSngA:9 a=wPNLvfGTeEIA:10 a=E9Po1WZjFZOl8hwRPBS3:22 a=9LHmKk7ezEChjTCyhBa9:22 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , dri-devel@lists.freedesktop.org, od@zcrc.me, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Paul, On Tue, Nov 10, 2020 at 08:50:22AM +0000, Paul Cercueil wrote: > Hi, > = > Le sam. 7 nov. 2020 =E0 20:33, Sam Ravnborg a =E9crit : > > Hi Paul. > > = > > On Thu, Nov 05, 2020 at 08:39:05AM +0000, Paul Cercueil wrote: > > > Increase the scaled image's theorical width/height until we find a > > > configuration that has valid scaling coefficients, up to 102% of the > > > screen's resolution. This makes sure that we can scale from almost > > > every resolution possible at the cost of a very small distorsion. > > > The CRTC_W / CRTC_H are not modified. > > > = > > > This algorithm was already in place but would not try to go above > > > the > > > screen's resolution, and as a result would only work if the CRTC_W / > > > CRTC_H were smaller than the screen resolution. It will now try > > > until it > > > reaches 102% of the screen's resolution. > > > = > > > Signed-off-by: Paul Cercueil > > = > > Looks like the patch does what the descriptions says. > > So in other words - look OK to me. I am not confident enogh for a r-b > > but my code reading is enough to warrant an a-b: > > Acked-by: Sam Ravnborg > = > Note that this algorithm exists mostly as a band-aid for a missing > functionality: it is not possible for userspace to request the closest mo= de > that would encapsulate the provided one, because the GEM buffer is created > beforehand. If there was a way to let the kernel tweak the mode, I could > write a better algorithm that would result in a better looking picture. Could you add this nice explanation to the changelog so when we wonder why this was done in some years we can dig up this from git history. Sam _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38094C55ABD for ; Tue, 10 Nov 2020 08:57:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD85E2080A for ; Tue, 10 Nov 2020 08:57:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727991AbgKJI5G (ORCPT ); Tue, 10 Nov 2020 03:57:06 -0500 Received: from asavdk3.altibox.net ([109.247.116.14]:48830 "EHLO asavdk3.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726467AbgKJI5F (ORCPT ); Tue, 10 Nov 2020 03:57:05 -0500 Received: from ravnborg.org (unknown [188.228.123.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk3.altibox.net (Postfix) with ESMTPS id 09C9F20038; Tue, 10 Nov 2020 09:56:59 +0100 (CET) Date: Tue, 10 Nov 2020 09:56:58 +0100 From: Sam Ravnborg To: Paul Cercueil Cc: David Airlie , Daniel Vetter , od@zcrc.me, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of?? the screen Message-ID: <20201110085658.GA2027451@ravnborg.org> References: <20201105083905.8780-1-paul@crapouillou.net> <20201107193311.GB1039949@ravnborg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=VbvZwmh9 c=1 sm=1 tr=0 a=S6zTFyMACwkrwXSdXUNehg==:117 a=S6zTFyMACwkrwXSdXUNehg==:17 a=8nJEP1OIZ-IA:10 a=7gkXJVJtAAAA:8 a=ER_8r6IbAAAA:8 a=9CIfjzEbJXW8LZeqSngA:9 a=wPNLvfGTeEIA:10 a=E9Po1WZjFZOl8hwRPBS3:22 a=9LHmKk7ezEChjTCyhBa9:22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, On Tue, Nov 10, 2020 at 08:50:22AM +0000, Paul Cercueil wrote: > Hi, > > Le sam. 7 nov. 2020 à 20:33, Sam Ravnborg a écrit : > > Hi Paul. > > > > On Thu, Nov 05, 2020 at 08:39:05AM +0000, Paul Cercueil wrote: > > > Increase the scaled image's theorical width/height until we find a > > > configuration that has valid scaling coefficients, up to 102% of the > > > screen's resolution. This makes sure that we can scale from almost > > > every resolution possible at the cost of a very small distorsion. > > > The CRTC_W / CRTC_H are not modified. > > > > > > This algorithm was already in place but would not try to go above > > > the > > > screen's resolution, and as a result would only work if the CRTC_W / > > > CRTC_H were smaller than the screen resolution. It will now try > > > until it > > > reaches 102% of the screen's resolution. > > > > > > Signed-off-by: Paul Cercueil > > > > Looks like the patch does what the descriptions says. > > So in other words - look OK to me. I am not confident enogh for a r-b > > but my code reading is enough to warrant an a-b: > > Acked-by: Sam Ravnborg > > Note that this algorithm exists mostly as a band-aid for a missing > functionality: it is not possible for userspace to request the closest mode > that would encapsulate the provided one, because the GEM buffer is created > beforehand. If there was a way to let the kernel tweak the mode, I could > write a better algorithm that would result in a better looking picture. Could you add this nice explanation to the changelog so when we wonder why this was done in some years we can dig up this from git history. Sam