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] [day] [month] [year] [list]

Date:   Tue, 10 Nov 2020 09:00:05 +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



Le mar. 10 nov. 2020 à 9:56, Sam Ravnborg <sam@...nborg.org> a écrit :
> 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 <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.
> 
> 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.

Sure!

-Paul