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 09:56:58 +0100
From:   Sam Ravnborg <sam@...nborg.org>
To:     Paul Cercueil <paul@...pouillou.net>
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 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.

	Sam