[PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[AngeloGioacchino Del Regno]

Hardware-speaking, there is no feature-reduced cursor specific
plane, so this driver reserves the last all Overlay plane as a
Cursor plane, but sets the maximum cursor width/height to the
maximum value that the full overlay plane can use.

While this could be ok, it raises issues with common userspace
using libdrm (especially Mutter, but other compositors too) which
will crash upon performing allocations and/or using said cursor
plane.

Reduce the maximum width/height for the cursor to 512x512 pixels,
value taken from IGT's maximum cursor size test, which succeeds.

Fixes: a4c9410b31ca ("drm/mediatek: Set DRM mode configs accordingly")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 6f0b415a978d..b96763664c4f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -540,8 +540,8 @@ static int mtk_drm_kms_init(struct drm_device *drm)
 	}
 
 	/* IGT will check if the cursor size is configured */
-	drm->mode_config.cursor_width = drm->mode_config.max_width;
-	drm->mode_config.cursor_height = drm->mode_config.max_height;
+	drm->mode_config.cursor_width = 512;
+	drm->mode_config.cursor_height = 512;
 
 	/* Use OVL device for all DMA memory allocations */
 	crtc = drm_crtc_from_index(drm, 0);
-- 
2.45.2

Re: [PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[Chen-Yu Tsai]

(CC-ed Fei Shao)

On Thu, Jul 18, 2024 at 4:24 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Hardware-speaking, there is no feature-reduced cursor specific
> plane, so this driver reserves the last all Overlay plane as a
> Cursor plane, but sets the maximum cursor width/height to the
> maximum value that the full overlay plane can use.
>
> While this could be ok, it raises issues with common userspace
> using libdrm (especially Mutter, but other compositors too) which
> will crash upon performing allocations and/or using said cursor
> plane.
>
> Reduce the maximum width/height for the cursor to 512x512 pixels,
> value taken from IGT's maximum cursor size test, which succeeds.
>
> Fixes: a4c9410b31ca ("drm/mediatek: Set DRM mode configs accordingly")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 6f0b415a978d..b96763664c4f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -540,8 +540,8 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>         }
>
>         /* IGT will check if the cursor size is configured */
> -       drm->mode_config.cursor_width = drm->mode_config.max_width;
> -       drm->mode_config.cursor_height = drm->mode_config.max_height;
> +       drm->mode_config.cursor_width = 512;
> +       drm->mode_config.cursor_height = 512;

Fei already did the same (?) workaround downstream just recently.

OOTH, Intel recently added a feature for enumerating "suggested"
cursor sizes. See https://patchwork.freedesktop.org/patch/583299/

Not sure if other compositors will end up using it or not.

ChenYu

>         /* Use OVL device for all DMA memory allocations */
>         crtc = drm_crtc_from_index(drm, 0);
> --
> 2.45.2
>

Re: [PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[Shawn Sung (宋孝謙)]

On Thu, 2024-07-18 at 16:49 +0800, Chen-Yu Tsai wrote:
>    
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  (CC-ed Fei Shao)
> 
> On Thu, Jul 18, 2024 at 4:24 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
 wrote:
> >
> > Hardware-speaking, there is no feature-reduced cursor specific
> > plane, so this driver reserves the last all Overlay plane as a
> > Cursor plane, but sets the maximum cursor width/height to the
> > maximum value that the full overlay plane can use.
> >
> > While this could be ok, it raises issues with common userspace
> > using libdrm (especially Mutter, but other compositors too) which
> > will crash upon performing allocations and/or using said cursor
> > plane.
> >
> > Reduce the maximum width/height for the cursor to 512x512 pixels,
> > value taken from IGT's maximum cursor size test, which succeeds.
> >
> > Fixes: a4c9410b31ca ("drm/mediatek: Set DRM mode configs
> accordingly")
> > Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno@collabora.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 6f0b415a978d..b96763664c4f 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -540,8 +540,8 @@ static int mtk_drm_kms_init(struct drm_device
> *drm)
> >         }
> >
> >         /* IGT will check if the cursor size is configured */
> > -       drm->mode_config.cursor_width = drm->mode_config.max_width;
> > -       drm->mode_config.cursor_height = drm-
> >mode_config.max_height;
> > +       drm->mode_config.cursor_width = 512;
> > +       drm->mode_config.cursor_height = 512;
> 
> Fei already did the same (?) workaround downstream just recently.
> 
> OOTH, Intel recently added a feature for enumerating "suggested"
> cursor sizes. See
https://patchwork.freedesktop.org/patch/583299/
> 
> Not sure if other compositors will end up using it or not.
> 
> ChenYu
> 
> >         /* Use OVL device for all DMA memory allocations */
> >         crtc = drm_crtc_from_index(drm, 0);
> > --
> > 2.45.2
> >

Just for more information, as the driver is describing the hardware limitation, and the comments for cursor_width/cursor_height in struct
drm_mode_config indicates "hint to userspace for 'max' cursor width/height". After few discussions with the reviewer, we eventually set it to the maximum size the Overlay supports (d46f652fc9fde61d7e88bfeace62f27847d55d40.camel@mediatek.com>).

Not sure if it makes sense for these userspace compositors to always
use the maximum size of the cursor plane as the cursor size.

Regards,
Shawn

Re: [PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[Fei Shao]

On Thu, Jul 18, 2024 at 4:49 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> (CC-ed Fei Shao)
>
> On Thu, Jul 18, 2024 at 4:24 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
> >
> > Hardware-speaking, there is no feature-reduced cursor specific
> > plane, so this driver reserves the last all Overlay plane as a
> > Cursor plane, but sets the maximum cursor width/height to the
> > maximum value that the full overlay plane can use.
> >
> > While this could be ok, it raises issues with common userspace
> > using libdrm (especially Mutter, but other compositors too) which
> > will crash upon performing allocations and/or using said cursor
> > plane.
> >
> > Reduce the maximum width/height for the cursor to 512x512 pixels,
> > value taken from IGT's maximum cursor size test, which succeeds.
> >
> > Fixes: a4c9410b31ca ("drm/mediatek: Set DRM mode configs accordingly")
> > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 6f0b415a978d..b96763664c4f 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -540,8 +540,8 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> >         }
> >
> >         /* IGT will check if the cursor size is configured */
> > -       drm->mode_config.cursor_width = drm->mode_config.max_width;
> > -       drm->mode_config.cursor_height = drm->mode_config.max_height;
> > +       drm->mode_config.cursor_width = 512;
> > +       drm->mode_config.cursor_height = 512;
>
> Fei already did the same (?) workaround downstream just recently.

Well, so another userspace gets confused...
I actually sent a separate userspace (i.e. Chrome) fix where I
encountered the issue, so I didn't proceed with upstreaming it in the
end.

This matches my preference in [1], so of course I'd like to see it
merged... if maintainers are okay with it.
Given I've tested the exact same change before:
Reviewed-by: Fei Shao <fshao@chromium.org>
Tested-by: Fei Shao <fshao@chromium.org>

[1]: https://lore.kernel.org/all/CAC=S1nhKPo5BUYJ_cHGz3OoPrWNh5eO8rhdyikLimsqSOrZ5Xg@mail.gmail.com/

Regards,
Fei
>
> OOTH, Intel recently added a feature for enumerating "suggested"
> cursor sizes. See https://patchwork.freedesktop.org/patch/583299/
>
> Not sure if other compositors will end up using it or not.
>
> ChenYu
>
> >         /* Use OVL device for all DMA memory allocations */
> >         crtc = drm_crtc_from_index(drm, 0);
> > --
> > 2.45.2
> >

Re: [PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[AngeloGioacchino Del Regno]

Il 18/07/24 11:27, Fei Shao ha scritto:
> On Thu, Jul 18, 2024 at 4:49 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>>
>> (CC-ed Fei Shao)
>>
>> On Thu, Jul 18, 2024 at 4:24 PM AngeloGioacchino Del Regno
>> <angelogioacchino.delregno@collabora.com> wrote:
>>>
>>> Hardware-speaking, there is no feature-reduced cursor specific
>>> plane, so this driver reserves the last all Overlay plane as a
>>> Cursor plane, but sets the maximum cursor width/height to the
>>> maximum value that the full overlay plane can use.
>>>
>>> While this could be ok, it raises issues with common userspace
>>> using libdrm (especially Mutter, but other compositors too) which
>>> will crash upon performing allocations and/or using said cursor
>>> plane.
>>>
>>> Reduce the maximum width/height for the cursor to 512x512 pixels,
>>> value taken from IGT's maximum cursor size test, which succeeds.
>>>
>>> Fixes: a4c9410b31ca ("drm/mediatek: Set DRM mode configs accordingly")
>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>> ---
>>>   drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>>> index 6f0b415a978d..b96763664c4f 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>>> @@ -540,8 +540,8 @@ static int mtk_drm_kms_init(struct drm_device *drm)
>>>          }
>>>
>>>          /* IGT will check if the cursor size is configured */
>>> -       drm->mode_config.cursor_width = drm->mode_config.max_width;
>>> -       drm->mode_config.cursor_height = drm->mode_config.max_height;
>>> +       drm->mode_config.cursor_width = 512;
>>> +       drm->mode_config.cursor_height = 512;
>>
>> Fei already did the same (?) workaround downstream just recently.

Heh, didn't know that :-D

> 
> Well, so another userspace gets confused...
> I actually sent a separate userspace (i.e. Chrome) fix where I
> encountered the issue, so I didn't proceed with upstreaming it in the
> end.
> 

Actually, there is a specific recipe that doesn't trigger this bug, that's why
I couldn't trigger it when reviewing the patch that was introducing it; if you
use a module instead of built-in, and insert it right after Panfrost, then you
will get stuff working - but with a performance penalty (and I upgraded my system
right before testing this patch, so I thought it happened because of the upgrade
and not because of this one).

After some more upgrades here and there, and seeing that I was on X11 and not
Wayland as usual, I was able to trigger this bug in any and every condition...

> This matches my preference in [1], so of course I'd like to see it
> merged... if maintainers are okay with it.
> Given I've tested the exact same change before:
> Reviewed-by: Fei Shao <fshao@chromium.org>
> Tested-by: Fei Shao <fshao@chromium.org>
> 

Thanks!

> [1]: https://lore.kernel.org/all/CAC=S1nhKPo5BUYJ_cHGz3OoPrWNh5eO8rhdyikLimsqSOrZ5Xg@mail.gmail.com/
> 
> Regards,
> Fei
>>
>> OOTH, Intel recently added a feature for enumerating "suggested"
>> cursor sizes. See https://patchwork.freedesktop.org/patch/583299/
>>
>> Not sure if other compositors will end up using it or not.

Yeah, that's good, and we might do that as well in MediaTek DRM... in a slightly
different way, as it looks like they are simply hinting the same values as the
mode_config is declaring... while we'd be adding a hint with a sensible size that
is less than the maximum supported one from the overlay.

In reality, here, the issue is that the most popular compositors do not support
overlay planes (as in, they don't use them at all)... my first idea was to remove
the CURSOR plane entirely and declare it as per what it is for real (an OVERLAY),
but that would only give a performance penalty as that'd become yet another unused
plane and nothing else.

If at least the most popular compositors did support overlay planes, I'd have done
that instead... but oh, well!

And anyway I hope that the maintainers are okay with this because, well, otherwise
MediaTek SoCs won't be usable with any popular WM.

Cheers!
Angelo

>>
>> ChenYu
>>
>>>          /* Use OVL device for all DMA memory allocations */
>>>          crtc = drm_crtc_from_index(drm, 0);
>>> --
>>> 2.45.2
>>>

Re: [PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[Daniel Stone]

Hi all,

On Thu, 18 Jul 2024 at 11:24, AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
> Il 18/07/24 11:27, Fei Shao ha scritto:
> > This matches my preference in [1], so of course I'd like to see it
> > merged... if maintainers are okay with it.
> > Given I've tested the exact same change before:
> > Reviewed-by: Fei Shao <fshao@chromium.org>
> > Tested-by: Fei Shao <fshao@chromium.org>
>
> Thanks!

And:
Reviewed-by: Daniel Stone <daniels@collabora.com>

> >> OOTH, Intel recently added a feature for enumerating "suggested"
> >> cursor sizes. See https://patchwork.freedesktop.org/patch/583299/
> >>
> >> Not sure if other compositors will end up using it or not.
>
> Yeah, that's good, and we might do that as well in MediaTek DRM... in a slightly
> different way, as it looks like they are simply hinting the same values as the
> mode_config is declaring... while we'd be adding a hint with a sensible size that
> is less than the maximum supported one from the overlay.
>
> In reality, here, the issue is that the most popular compositors do not support
> overlay planes (as in, they don't use them at all)... my first idea was to remove
> the CURSOR plane entirely and declare it as per what it is for real (an OVERLAY),
> but that would only give a performance penalty as that'd become yet another unused
> plane and nothing else.
>
> If at least the most popular compositors did support overlay planes, I'd have done
> that instead... but oh, well!
>
> And anyway I hope that the maintainers are okay with this because, well, otherwise
> MediaTek SoCs won't be usable with any popular WM.

Every compositor is going to use it, yeah. But until it does, people
are just going to use cursor_width and cursor_size. A lot of older
desktop hardware supports only a single fixed dimension for the cursor
plane (hence the single values), so rather than guess if it needs to
be 32x32 or 64x64 or whatever, people just allocate to the size. Not
to mention that the old pre-atomic cursor ioctls actually require that
you allocate for cursor_width x cursor_height.

So yeah, this is the right fix - though you could even be more
aggressive and reduce it to 256x256 - and supporting the CURSOR_SIZE
property would be even more useful again.

Cheers,
Daniel

Re: [PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[AngeloGioacchino Del Regno]

Il 18/07/24 13:10, Daniel Stone ha scritto:
> Hi all,
> 
> On Thu, 18 Jul 2024 at 11:24, AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>> Il 18/07/24 11:27, Fei Shao ha scritto:
>>> This matches my preference in [1], so of course I'd like to see it
>>> merged... if maintainers are okay with it.
>>> Given I've tested the exact same change before:
>>> Reviewed-by: Fei Shao <fshao@chromium.org>
>>> Tested-by: Fei Shao <fshao@chromium.org>
>>
>> Thanks!
> 
> And:
> Reviewed-by: Daniel Stone <daniels@collabora.com>
> 
>>>> OOTH, Intel recently added a feature for enumerating "suggested"
>>>> cursor sizes. See https://patchwork.freedesktop.org/patch/583299/
>>>>
>>>> Not sure if other compositors will end up using it or not.
>>
>> Yeah, that's good, and we might do that as well in MediaTek DRM... in a slightly
>> different way, as it looks like they are simply hinting the same values as the
>> mode_config is declaring... while we'd be adding a hint with a sensible size that
>> is less than the maximum supported one from the overlay.
>>
>> In reality, here, the issue is that the most popular compositors do not support
>> overlay planes (as in, they don't use them at all)... my first idea was to remove
>> the CURSOR plane entirely and declare it as per what it is for real (an OVERLAY),
>> but that would only give a performance penalty as that'd become yet another unused
>> plane and nothing else.
>>
>> If at least the most popular compositors did support overlay planes, I'd have done
>> that instead... but oh, well!
>>
>> And anyway I hope that the maintainers are okay with this because, well, otherwise
>> MediaTek SoCs won't be usable with any popular WM.
> 
> Every compositor is going to use it, yeah. But until it does, people
> are just going to use cursor_width and cursor_size. A lot of older
> desktop hardware supports only a single fixed dimension for the cursor
> plane (hence the single values), so rather than guess if it needs to
> be 32x32 or 64x64 or whatever, people just allocate to the size. Not
> to mention that the old pre-atomic cursor ioctls actually require that
> you allocate for cursor_width x cursor_height.
> 
> So yeah, this is the right fix - though you could even be more
> aggressive and reduce it to 256x256 - and supporting the CURSOR_SIZE
> property would be even more useful again.
> 

I thought about being more aggressive, but then I saw that IGT tests for up to 512
and that MSM also declares the same, so, making IGT happy because we can indeed
support that much (since we can support even more, but doesn't make sense) :-)

Regarding CURSOR_SIZE ... right, I can take a look at that a bit later, most
probably not for this merge window, though.

Cheers!

> Cheers,
> Daniel

Re: [PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[CK Hu (胡俊光)]

Hi, Angelo:

On Thu, 2024-07-18 at 13:23 +0200, AngeloGioacchino Del Regno wrote:
> Il 18/07/24 13:10, Daniel Stone ha scritto:
> > Hi all,
> > 
> > On Thu, 18 Jul 2024 at 11:24, AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com> wrote:
> > > Il 18/07/24 11:27, Fei Shao ha scritto:
> > > > This matches my preference in [1], so of course I'd like to see it
> > > > merged... if maintainers are okay with it.
> > > > Given I've tested the exact same change before:
> > > > Reviewed-by: Fei Shao <fshao@chromium.org>
> > > > Tested-by: Fei Shao <fshao@chromium.org>
> > > 
> > > Thanks!
> > 
> > And:
> > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > 
> > > > > OOTH, Intel recently added a feature for enumerating "suggested"
> > > > > cursor sizes. See https://urldefense.com/v3/__https://patchwork.freedesktop.org/patch/583299/__;!!CTRNKA9wMg0ARbw!nRf6mf-9tnE7vLYracLE6Xq_oblRvtENffF73fRzgz_E3zPc3yxeQPE5yPw95sj-ZeoiYJCQSIPWFZ0C3HCXpBkHikWK$ 
> > > > > 
> > > > > Not sure if other compositors will end up using it or not.
> > > 
> > > Yeah, that's good, and we might do that as well in MediaTek DRM... in a slightly
> > > different way, as it looks like they are simply hinting the same values as the
> > > mode_config is declaring... while we'd be adding a hint with a sensible size that
> > > is less than the maximum supported one from the overlay.
> > > 
> > > In reality, here, the issue is that the most popular compositors do not support
> > > overlay planes (as in, they don't use them at all)... my first idea was to remove
> > > the CURSOR plane entirely and declare it as per what it is for real (an OVERLAY),
> > > but that would only give a performance penalty as that'd become yet another unused
> > > plane and nothing else.
> > > 
> > > If at least the most popular compositors did support overlay planes, I'd have done
> > > that instead... but oh, well!
> > > 
> > > And anyway I hope that the maintainers are okay with this because, well, otherwise
> > > MediaTek SoCs won't be usable with any popular WM.
> > 
> > Every compositor is going to use it, yeah. But until it does, people
> > are just going to use cursor_width and cursor_size. A lot of older
> > desktop hardware supports only a single fixed dimension for the cursor
> > plane (hence the single values), so rather than guess if it needs to
> > be 32x32 or 64x64 or whatever, people just allocate to the size. Not
> > to mention that the old pre-atomic cursor ioctls actually require that
> > you allocate for cursor_width x cursor_height.
> > 
> > So yeah, this is the right fix - though you could even be more
> > aggressive and reduce it to 256x256 - and supporting the CURSOR_SIZE
> > property would be even more useful again.
> > 
> 
> I thought about being more aggressive, but then I saw that IGT tests for up to 512
> and that MSM also declares the same, so, making IGT happy because we can indeed
> support that much (since we can support even more, but doesn't make sense) :-)
> 
> Regarding CURSOR_SIZE ... right, I can take a look at that a bit later, most
> probably not for this merge window, though.

This patch looks acceptable but it could be better.
It's urgent to fix the crash, if better solution does not come out soon,
I would apply this patch first.

Reviewed-by: CK Hu <ck.hu@mediatek.com>

I will remove the Fixes tag because Shawn's patch has no logical problem but the system resource is not enough.

It's a dilemma that small size has no resource problem but application is limited
and large size has resource problem but support more application.

Regards,
CK

> 
> Cheers!
> 
> > Cheers,
> > Daniel
> 
> 

Re: [PATCH] drm/mediatek: Set sensible cursor width/height values to fix crash

[AngeloGioacchino Del Regno]

Il 19/07/24 10:42, CK Hu (胡俊光) ha scritto:
> Hi, Angelo:
> 
> On Thu, 2024-07-18 at 13:23 +0200, AngeloGioacchino Del Regno wrote:
>> Il 18/07/24 13:10, Daniel Stone ha scritto:
>>> Hi all,
>>>
>>> On Thu, 18 Jul 2024 at 11:24, AngeloGioacchino Del Regno
>>> <angelogioacchino.delregno@collabora.com> wrote:
>>>> Il 18/07/24 11:27, Fei Shao ha scritto:
>>>>> This matches my preference in [1], so of course I'd like to see it
>>>>> merged... if maintainers are okay with it.
>>>>> Given I've tested the exact same change before:
>>>>> Reviewed-by: Fei Shao <fshao@chromium.org>
>>>>> Tested-by: Fei Shao <fshao@chromium.org>
>>>>
>>>> Thanks!
>>>
>>> And:
>>> Reviewed-by: Daniel Stone <daniels@collabora.com>
>>>
>>>>>> OOTH, Intel recently added a feature for enumerating "suggested"
>>>>>> cursor sizes. See https://urldefense.com/v3/__https://patchwork.freedesktop.org/patch/583299/__;!!CTRNKA9wMg0ARbw!nRf6mf-9tnE7vLYracLE6Xq_oblRvtENffF73fRzgz_E3zPc3yxeQPE5yPw95sj-ZeoiYJCQSIPWFZ0C3HCXpBkHikWK$
>>>>>>
>>>>>> Not sure if other compositors will end up using it or not.
>>>>
>>>> Yeah, that's good, and we might do that as well in MediaTek DRM... in a slightly
>>>> different way, as it looks like they are simply hinting the same values as the
>>>> mode_config is declaring... while we'd be adding a hint with a sensible size that
>>>> is less than the maximum supported one from the overlay.
>>>>
>>>> In reality, here, the issue is that the most popular compositors do not support
>>>> overlay planes (as in, they don't use them at all)... my first idea was to remove
>>>> the CURSOR plane entirely and declare it as per what it is for real (an OVERLAY),
>>>> but that would only give a performance penalty as that'd become yet another unused
>>>> plane and nothing else.
>>>>
>>>> If at least the most popular compositors did support overlay planes, I'd have done
>>>> that instead... but oh, well!
>>>>
>>>> And anyway I hope that the maintainers are okay with this because, well, otherwise
>>>> MediaTek SoCs won't be usable with any popular WM.
>>>
>>> Every compositor is going to use it, yeah. But until it does, people
>>> are just going to use cursor_width and cursor_size. A lot of older
>>> desktop hardware supports only a single fixed dimension for the cursor
>>> plane (hence the single values), so rather than guess if it needs to
>>> be 32x32 or 64x64 or whatever, people just allocate to the size. Not
>>> to mention that the old pre-atomic cursor ioctls actually require that
>>> you allocate for cursor_width x cursor_height.
>>>
>>> So yeah, this is the right fix - though you could even be more
>>> aggressive and reduce it to 256x256 - and supporting the CURSOR_SIZE
>>> property would be even more useful again.
>>>
>>
>> I thought about being more aggressive, but then I saw that IGT tests for up to 512
>> and that MSM also declares the same, so, making IGT happy because we can indeed
>> support that much (since we can support even more, but doesn't make sense) :-)
>>
>> Regarding CURSOR_SIZE ... right, I can take a look at that a bit later, most
>> probably not for this merge window, though.
> 
> This patch looks acceptable but it could be better.
> It's urgent to fix the crash, if better solution does not come out soon,
> I would apply this patch first.
> 
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> 
> I will remove the Fixes tag because Shawn's patch has no logical problem but the system resource is not enough.
> 
> It's a dilemma that small size has no resource problem but application is limited
> and large size has resource problem but support more application.
> 

Thanks, but the Fixes tag is important, as otherwise v6.11 will be unusable :-)

Regards,
Angelo

> Regards,
> CK
> 
>>
>> Cheers!
>>
>>> Cheers,
>>> Daniel
>>
>>