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 <[email protected]>
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-ipu.c b/drivers/gpu/drm/ingenic/ingenic-ipu.c
index fc8c6e970ee3..e52777ef85fd 100644
--- a/drivers/gpu/drm/ingenic/ingenic-ipu.c
+++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c
@@ -516,7 +516,7 @@ static void ingenic_ipu_plane_atomic_update(struct drm_plane *plane,
static int ingenic_ipu_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
- unsigned int num_w, denom_w, num_h, denom_h, xres, yres;
+ unsigned int num_w, denom_w, num_h, denom_h, xres, yres, max_w, max_h;
struct ingenic_ipu *ipu = plane_to_ingenic_ipu(plane);
struct drm_crtc *crtc = state->crtc ?: plane->state->crtc;
struct drm_crtc_state *crtc_state;
@@ -558,19 +558,26 @@ static int ingenic_ipu_plane_atomic_check(struct drm_plane *plane,
xres = state->src_w >> 16;
yres = state->src_h >> 16;
- /* Adjust the coefficients until we find a valid configuration */
- for (denom_w = xres, num_w = state->crtc_w;
- num_w <= crtc_state->mode.hdisplay; num_w++)
+ /*
+ * 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.
+ */
+ max_w = crtc_state->mode.hdisplay * 102 / 100;
+ max_h = crtc_state->mode.vdisplay * 102 / 100;
+
+ for (denom_w = xres, num_w = state->crtc_w; num_w <= max_w; num_w++)
if (!reduce_fraction(&num_w, &denom_w))
break;
- if (num_w > crtc_state->mode.hdisplay)
+ if (num_w > max_w)
return -EINVAL;
- for (denom_h = yres, num_h = state->crtc_h;
- num_h <= crtc_state->mode.vdisplay; num_h++)
+ for (denom_h = yres, num_h = state->crtc_h; num_h <= max_h; num_h++)
if (!reduce_fraction(&num_h, &denom_h))
break;
- if (num_h > crtc_state->mode.vdisplay)
+ if (num_h > max_h)
return -EINVAL;
ipu->num_w = num_w;
--
2.28.0
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 <[email protected]>
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 <[email protected]>
Hi,
Le sam. 7 nov. 2020 ? 20:33, Sam Ravnborg <[email protected]> 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 <[email protected]>
>
> 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 <[email protected]>
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
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 <[email protected]> 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 <[email protected]>
> >
> > 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 <[email protected]>
>
> 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
Le mar. 10 nov. 2020 ? 9:56, Sam Ravnborg <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> >
>> > 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 <[email protected]>
>>
>> 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