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.8 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 148C0C56201 for ; Wed, 11 Nov 2020 07:55:42 +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 AB0DC206B5 for ; Wed, 11 Nov 2020 07:55:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AB0DC206B5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=crapouillou.net 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 45DA889EFF; Wed, 11 Nov 2020 07:54:47 +0000 (UTC) Received: from aposti.net (aposti.net [89.234.176.197]) by gabe.freedesktop.org (Postfix) with ESMTPS id DC66A89801 for ; Tue, 10 Nov 2020 08:50:37 +0000 (UTC) Date: Tue, 10 Nov 2020 08:50:22 +0000 From: Paul Cercueil Subject: Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% =?UTF-8?Q?of=0D=0A?= the screen To: Sam Ravnborg Message-Id: In-Reply-To: <20201107193311.GB1039949@ravnborg.org> References: <20201105083905.8780-1-paul@crapouillou.net> <20201107193311.GB1039949@ravnborg.org> MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Nov 2020 07:54:43 +0000 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 = 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. Cheers, -Paul _______________________________________________ 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 256FBC5517A for ; Tue, 10 Nov 2020 08:50:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C54A3207BC for ; Tue, 10 Nov 2020 08:50:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729301AbgKJIuh convert rfc822-to-8bit (ORCPT ); Tue, 10 Nov 2020 03:50:37 -0500 Received: from aposti.net ([89.234.176.197]:34636 "EHLO aposti.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726213AbgKJIug (ORCPT ); Tue, 10 Nov 2020 03:50:36 -0500 Date: Tue, 10 Nov 2020 08:50:22 +0000 From: Paul Cercueil Subject: Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% =?UTF-8?Q?of=0D=0A?= the screen To: Sam Ravnborg Cc: David Airlie , Daniel Vetter , od@zcrc.me, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Message-Id: In-Reply-To: <20201107193311.GB1039949@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; format=flowed Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Cheers, -Paul