From: Paul Cercueil <paul@crapouillou.net>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: David Airlie <airlied@linux.ie>,
dri-devel@lists.freedesktop.org, od@zcrc.me,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102%\r
of?? the screen
Date: Tue, 10 Nov 2020 09:00:05 +0000 [thread overview]
Message-ID: <50PKJQ.NE1WVCA2FLEF3@crapouillou.net> (raw)
In-Reply-To: <20201110085658.GA2027451@ravnborg.org>
Le mar. 10 nov. 2020 à 9:56, Sam Ravnborg <sam@ravnborg.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@ravnborg.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@crapouillou.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@ravnborg.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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Paul Cercueil <paul@crapouillou.net>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
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%\r
of?? the screen
Date: Tue, 10 Nov 2020 09:00:05 +0000 [thread overview]
Message-ID: <50PKJQ.NE1WVCA2FLEF3@crapouillou.net> (raw)
In-Reply-To: <20201110085658.GA2027451@ravnborg.org>
Le mar. 10 nov. 2020 à 9:56, Sam Ravnborg <sam@ravnborg.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@ravnborg.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@crapouillou.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@ravnborg.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
next prev parent reply other threads:[~2020-11-11 7:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-05 8:39 [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of the screen Paul Cercueil
2020-11-05 8:39 ` Paul Cercueil
2020-11-07 19:33 ` Sam Ravnborg
2020-11-07 19:33 ` Sam Ravnborg
2020-11-10 8:50 ` Paul Cercueil
2020-11-10 8:50 ` Paul Cercueil
2020-11-10 8:56 ` [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of?? " Sam Ravnborg
2020-11-10 8:56 ` Sam Ravnborg
2020-11-10 9:00 ` Paul Cercueil [this message]
2020-11-10 9:00 ` Paul Cercueil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50PKJQ.NE1WVCA2FLEF3@crapouillou.net \
--to=paul@crapouillou.net \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=od@zcrc.me \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.