Hi DRM subsystem developers,
I ran into this patch where overlay plane was switched to cursor plane
because there was no proper cursor plane available on the display
hardware: <https://lkml.org/lkml/2018/3/17/120>. Can we discuss whether
to have a policy of using a normal plane for cursor plane in case a
dedicated HW cursor plane is missing?
Daniel Vetter suggests that it might be fine to use normal plane for
cursor plane because how to use the plane would be only "a hint to
userspace" (see the email linked).
My motivation for having this discussion is that the newer Allwinner
SoCs don't have dedicated HW cursor plane and the sun4i DRM driver
currently uses the extra planes as overlay planes which makes moving the
cursor on Xfce4 DE a terrible experience. To have better cursor moving
experience one overlay plane would need to be sacrificed.
Also, I probably missed some recipients for this email so please forward
it to the recipients you think might be interested about this.
Best regards,
Joonas
On Mon, Mar 26, 2018 at 10:14 PM, Joonas Kylmälä <[email protected]> wrote:
> Hi DRM subsystem developers,
>
> I ran into this patch where overlay plane was switched to cursor plane
> because there was no proper cursor plane available on the display
> hardware: <https://lkml.org/lkml/2018/3/17/120>. Can we discuss whether
> to have a policy of using a normal plane for cursor plane in case a
> dedicated HW cursor plane is missing?
>
> Daniel Vetter suggests that it might be fine to use normal plane for
> cursor plane because how to use the plane would be only "a hint to
> userspace" (see the email linked).
>
> My motivation for having this discussion is that the newer Allwinner
> SoCs don't have dedicated HW cursor plane and the sun4i DRM driver
> currently uses the extra planes as overlay planes which makes moving the
> cursor on Xfce4 DE a terrible experience. To have better cursor moving
> experience one overlay plane would need to be sacrificed.
If you look at the development history, we've never supported cursor planes.
At the beginning we supported one main plane and one overlay plane. That was
it. The Display Engine 1.0 does have support for an extra hardware cursor,
but we haven't done the work to support it yet. I don't know about the
Display Engine 2.0 though.
ChenYu
> Also, I probably missed some recipients for this email so please forward
> it to the recipients you think might be interested about this.
>
> Best regards,
> Joonas
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
On Mon, Mar 26, 2018 at 10:22:45PM +0800, Chen-Yu Tsai wrote:
> On Mon, Mar 26, 2018 at 10:14 PM, Joonas Kylm?l? <[email protected]> wrote:
> > Hi DRM subsystem developers,
> >
> > I ran into this patch where overlay plane was switched to cursor plane
> > because there was no proper cursor plane available on the display
> > hardware: <https://lkml.org/lkml/2018/3/17/120>. Can we discuss whether
> > to have a policy of using a normal plane for cursor plane in case a
> > dedicated HW cursor plane is missing?
> >
> > Daniel Vetter suggests that it might be fine to use normal plane for
> > cursor plane because how to use the plane would be only "a hint to
> > userspace" (see the email linked).
> >
> > My motivation for having this discussion is that the newer Allwinner
> > SoCs don't have dedicated HW cursor plane and the sun4i DRM driver
> > currently uses the extra planes as overlay planes which makes moving the
> > cursor on Xfce4 DE a terrible experience. To have better cursor moving
> > experience one overlay plane would need to be sacrificed.
>
> If you look at the development history, we've never supported cursor planes.
X can use an overlay to put the cursor though.
> At the beginning we supported one main plane and one overlay plane. That was
> it. The Display Engine 1.0 does have support for an extra hardware cursor,
> but we haven't done the work to support it yet. I don't know about the
> Display Engine 2.0 though.
An issue with supporting the hardware cursor we have is that as far as
I understood, the cursor plane in DRM has the assumption that it would
be an ARGB format. In the first display engine, the format is actually
an 8-bit palette with 1 bit of alpha iirc.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
On Mon, Mar 26, 2018 at 10:45 PM, Maxime Ripard
<[email protected]> wrote:
> On Mon, Mar 26, 2018 at 10:22:45PM +0800, Chen-Yu Tsai wrote:
>> On Mon, Mar 26, 2018 at 10:14 PM, Joonas Kylmälä <[email protected]> wrote:
>> > Hi DRM subsystem developers,
>> >
>> > I ran into this patch where overlay plane was switched to cursor plane
>> > because there was no proper cursor plane available on the display
>> > hardware: <https://lkml.org/lkml/2018/3/17/120>. Can we discuss whether
>> > to have a policy of using a normal plane for cursor plane in case a
>> > dedicated HW cursor plane is missing?
>> >
>> > Daniel Vetter suggests that it might be fine to use normal plane for
>> > cursor plane because how to use the plane would be only "a hint to
>> > userspace" (see the email linked).
>> >
>> > My motivation for having this discussion is that the newer Allwinner
>> > SoCs don't have dedicated HW cursor plane and the sun4i DRM driver
>> > currently uses the extra planes as overlay planes which makes moving the
>> > cursor on Xfce4 DE a terrible experience. To have better cursor moving
>> > experience one overlay plane would need to be sacrificed.
>>
>> If you look at the development history, we've never supported cursor planes.
>
> X can use an overlay to put the cursor though.
>
>> At the beginning we supported one main plane and one overlay plane. That was
>> it. The Display Engine 1.0 does have support for an extra hardware cursor,
>> but we haven't done the work to support it yet. I don't know about the
>> Display Engine 2.0 though.
>
> An issue with supporting the hardware cursor we have is that as far as
> I understood, the cursor plane in DRM has the assumption that it would
> be an ARGB format. In the first display engine, the format is actually
> an 8-bit palette with 1 bit of alpha iirc.
Looks like it's 32x32 pixels with an 8-bit (max) palette, with full RGBA
for the colors in the palette. I don't see the 1 bit alpha you mentioned.
Looks like this needs some extra work for building the palette and copying
the cursor image.
ChenYu
On Mon, Mar 26, 2018 at 11:01:53PM +0800, Chen-Yu Tsai wrote:
> On Mon, Mar 26, 2018 at 10:45 PM, Maxime Ripard
> <[email protected]> wrote:
> > On Mon, Mar 26, 2018 at 10:22:45PM +0800, Chen-Yu Tsai wrote:
> >> On Mon, Mar 26, 2018 at 10:14 PM, Joonas Kylm?l? <[email protected]> wrote:
> >> > Hi DRM subsystem developers,
> >> >
> >> > I ran into this patch where overlay plane was switched to cursor plane
> >> > because there was no proper cursor plane available on the display
> >> > hardware: <https://lkml.org/lkml/2018/3/17/120>. Can we discuss whether
> >> > to have a policy of using a normal plane for cursor plane in case a
> >> > dedicated HW cursor plane is missing?
> >> >
> >> > Daniel Vetter suggests that it might be fine to use normal plane for
> >> > cursor plane because how to use the plane would be only "a hint to
> >> > userspace" (see the email linked).
> >> >
> >> > My motivation for having this discussion is that the newer Allwinner
> >> > SoCs don't have dedicated HW cursor plane and the sun4i DRM driver
> >> > currently uses the extra planes as overlay planes which makes moving the
> >> > cursor on Xfce4 DE a terrible experience. To have better cursor moving
> >> > experience one overlay plane would need to be sacrificed.
> >>
> >> If you look at the development history, we've never supported cursor planes.
> >
> > X can use an overlay to put the cursor though.
> >
> >> At the beginning we supported one main plane and one overlay plane. That was
> >> it. The Display Engine 1.0 does have support for an extra hardware cursor,
> >> but we haven't done the work to support it yet. I don't know about the
> >> Display Engine 2.0 though.
> >
> > An issue with supporting the hardware cursor we have is that as far as
> > I understood, the cursor plane in DRM has the assumption that it would
> > be an ARGB format. In the first display engine, the format is actually
> > an 8-bit palette with 1 bit of alpha iirc.
>
> Looks like it's 32x32 pixels with an 8-bit (max) palette, with full RGBA
> for the colors in the palette. I don't see the 1 bit alpha you mentioned.
> Looks like this needs some extra work for building the palette and copying
> the cursor image.
Indeed, you're right. I'm still not sure how it could be turned into
something useful though.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com