linux-kernel - Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of the screen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Nov 2020 08:50:22 +0000
From:   Paul Cercueil <paul@...pouillou.net>
To:     Sam Ravnborg <sam@...nborg.org>
Cc:     David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>,
        od@...c.me, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102%
 of
 the screen

Hi,

Le sam. 7 nov. 2020 à 20:33, Sam Ravnborg <sam@...nborg.org> 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 <paul@...pouillou.net>
> 
> 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 <sam@...nborg.org>

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