display band (display area vs real visible area)

display band (display area vs real visible area)

[Michael Nazzareno Trimarchi]

Hi all

I would like to know the best approach in the graphics subsystem how
deal with panels where the display area is different from the visible
area because the display has a band left and right. I have already
done the drm driver for the panel but from userspace point of view
it's a pain to deal in wayland for input device and output device. Do
you have any suggestions?

Regards
Michael

Re: display band (display area vs real visible area)

[Jani Nikula]

On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
> Hi all
>
> I would like to know the best approach in the graphics subsystem how
> deal with panels where the display area is different from the visible
> area because the display has a band left and right. I have already
> done the drm driver for the panel but from userspace point of view
> it's a pain to deal in wayland for input device and output device. Do
> you have any suggestions?

Do you have the EDID for the panel?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: display band (display area vs real visible area)

[Michael Nazzareno Trimarchi]

Hi

On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
<jani.nikula@linux.intel.com> wrote:
>
> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
> > Hi all
> >
> > I would like to know the best approach in the graphics subsystem how
> > deal with panels where the display area is different from the visible
> > area because the display has a band left and right. I have already
> > done the drm driver for the panel but from userspace point of view
> > it's a pain to deal in wayland for input device and output device. Do
> > you have any suggestions?
>
> Do you have the EDID for the panel?

mipi->panel so should not have edid

Michael

>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Graphics Center



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

Re: display band (display area vs real visible area)

[Jani Nikula]

On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
> Hi
>
> On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
> <jani.nikula@linux.intel.com> wrote:
>>
>> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
>> > Hi all
>> >
>> > I would like to know the best approach in the graphics subsystem how
>> > deal with panels where the display area is different from the visible
>> > area because the display has a band left and right. I have already
>> > done the drm driver for the panel but from userspace point of view
>> > it's a pain to deal in wayland for input device and output device. Do
>> > you have any suggestions?
>>
>> Do you have the EDID for the panel?
>
> mipi->panel so should not have edid

That's the kind of information you'd expect in the original question. ;)

I've done that sort of thing in the past, but not sure if it would fly
upstream. Basically the kernel driver would lie about the resolution to
userspace, and handle the centering and the bands internally. In my
case, the DSI command mode panel in question had commands to set the
visible area, so the driver didn't have to do all that much extra to
make it happen.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: display band (display area vs real visible area)

[Daniel Stone]

Hi,

On Tue, 21 Mar 2023 at 11:24, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
> > On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
> > <jani.nikula@linux.intel.com> wrote:
> >> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
> >> > I would like to know the best approach in the graphics subsystem how
> >> > deal with panels where the display area is different from the visible
> >> > area because the display has a band left and right. I have already
> >> > done the drm driver for the panel but from userspace point of view
> >> > it's a pain to deal in wayland for input device and output device. Do
> >> > you have any suggestions?
> >>
> >> Do you have the EDID for the panel?
> >
> > mipi->panel so should not have edid
>
> That's the kind of information you'd expect in the original question. ;)
>
> I've done that sort of thing in the past, but not sure if it would fly
> upstream. Basically the kernel driver would lie about the resolution to
> userspace, and handle the centering and the bands internally. In my
> case, the DSI command mode panel in question had commands to set the
> visible area, so the driver didn't have to do all that much extra to
> make it happen.

There have been some threads - mostly motivated by MacBooks and the
Asahi team - about creating a KMS property to express invisible areas.
This would be the same thing, and the userspace ecosystem will pick it
up when the kernel exposes it.

Cheers,
Daniel

Re: display band (display area vs real visible area)

[Michael Nazzareno Trimarchi]

Hi Daniel

On Tue, Mar 21, 2023 at 12:49 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> Hi,
>
> On Tue, 21 Mar 2023 at 11:24, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
> > > On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
> > > <jani.nikula@linux.intel.com> wrote:
> > >> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
> > >> > I would like to know the best approach in the graphics subsystem how
> > >> > deal with panels where the display area is different from the visible
> > >> > area because the display has a band left and right. I have already
> > >> > done the drm driver for the panel but from userspace point of view
> > >> > it's a pain to deal in wayland for input device and output device. Do
> > >> > you have any suggestions?
> > >>
> > >> Do you have the EDID for the panel?
> > >
> > > mipi->panel so should not have edid
> >
> > That's the kind of information you'd expect in the original question. ;)
> >
> > I've done that sort of thing in the past, but not sure if it would fly
> > upstream. Basically the kernel driver would lie about the resolution to
> > userspace, and handle the centering and the bands internally. In my
> > case, the DSI command mode panel in question had commands to set the
> > visible area, so the driver didn't have to do all that much extra to
> > make it happen.
>
> There have been some threads - mostly motivated by MacBooks and the
> Asahi team - about creating a KMS property to express invisible areas.
> This would be the same thing, and the userspace ecosystem will pick it
> up when the kernel exposes it.
>
> Cheers,
> Daniel

Any thread or patches?

Michael

Re: display band (display area vs real visible area)

[Jani Nikula]

On Tue, 21 Mar 2023, Daniel Stone <daniel@fooishbar.org> wrote:
> Hi,
>
> On Tue, 21 Mar 2023 at 11:24, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
>> > On Tue, Mar 21, 2023 at 11:43 AM Jani Nikula
>> > <jani.nikula@linux.intel.com> wrote:
>> >> On Tue, 21 Mar 2023, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:
>> >> > I would like to know the best approach in the graphics subsystem how
>> >> > deal with panels where the display area is different from the visible
>> >> > area because the display has a band left and right. I have already
>> >> > done the drm driver for the panel but from userspace point of view
>> >> > it's a pain to deal in wayland for input device and output device. Do
>> >> > you have any suggestions?
>> >>
>> >> Do you have the EDID for the panel?
>> >
>> > mipi->panel so should not have edid
>>
>> That's the kind of information you'd expect in the original question. ;)
>>
>> I've done that sort of thing in the past, but not sure if it would fly
>> upstream. Basically the kernel driver would lie about the resolution to
>> userspace, and handle the centering and the bands internally. In my
>> case, the DSI command mode panel in question had commands to set the
>> visible area, so the driver didn't have to do all that much extra to
>> make it happen.
>
> There have been some threads - mostly motivated by MacBooks and the
> Asahi team - about creating a KMS property to express invisible areas.
> This would be the same thing, and the userspace ecosystem will pick it
> up when the kernel exposes it.

In my case the kernel handled it completely internally, and the
userspace didn't even know. But I guess it depends on the display being
able to take a smaller framebuffer, otherwise I don't think it's
feasible.

I haven't checked the threads you mention but I assume it covers the
more general case of having rounded corners or holes for the camera, not
just the frame covering the edges or something like that. That couldn't
possibly be handled by kernel alone, but it's also a bunch of
infrastructure work both in kernel and userspace to make it happen.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: display band (display area vs real visible area)

[Daniel Stone]

Hi,

On Tue, 21 Mar 2023 at 12:08, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Tue, 21 Mar 2023, Daniel Stone <daniel@fooishbar.org> wrote:
> > There have been some threads - mostly motivated by MacBooks and the
> > Asahi team - about creating a KMS property to express invisible areas.
> > This would be the same thing, and the userspace ecosystem will pick it
> > up when the kernel exposes it.
>
> In my case the kernel handled it completely internally, and the
> userspace didn't even know. But I guess it depends on the display being
> able to take a smaller framebuffer, otherwise I don't think it's
> feasible.
>
> I haven't checked the threads you mention but I assume it covers the
> more general case of having rounded corners or holes for the camera, not
> just the frame covering the edges or something like that. That couldn't
> possibly be handled by kernel alone, but it's also a bunch of
> infrastructure work both in kernel and userspace to make it happen.

Yeah, exactly. Just a connector property, which could come from DT or
ACPI or manual overrides or whatever. Userspace would still allocate a
full-size framebuffer, but look at that property and not render
anything useful into those areas. In the camera/notch case, it's a
matter of not putting useful content there. In the letterbox/pillarbox
case, it's about shrinking the reported screen size so that window
management, clients, etc, all believe that the screen is smaller than
it is.

Cheers,
Daniel

Re: display band (display area vs real visible area)

[Michael Nazzareno Trimarchi]

Hi Daniel

On Tue, Mar 21, 2023 at 1:15 PM Daniel Stone <daniel@fooishbar.org> wrote:
>
> Hi,
>
> On Tue, 21 Mar 2023 at 12:08, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > On Tue, 21 Mar 2023, Daniel Stone <daniel@fooishbar.org> wrote:
> > > There have been some threads - mostly motivated by MacBooks and the
> > > Asahi team - about creating a KMS property to express invisible areas.
> > > This would be the same thing, and the userspace ecosystem will pick it
> > > up when the kernel exposes it.
> >
> > In my case the kernel handled it completely internally, and the
> > userspace didn't even know. But I guess it depends on the display being
> > able to take a smaller framebuffer, otherwise I don't think it's
> > feasible.
> >
> > I haven't checked the threads you mention but I assume it covers the
> > more general case of having rounded corners or holes for the camera, not
> > just the frame covering the edges or something like that. That couldn't
> > possibly be handled by kernel alone, but it's also a bunch of
> > infrastructure work both in kernel and userspace to make it happen.
>
> Yeah, exactly. Just a connector property, which could come from DT or
> ACPI or manual overrides or whatever. Userspace would still allocate a
> full-size framebuffer, but look at that property and not render
> anything useful into those areas. In the camera/notch case, it's a
> matter of not putting useful content there. In the letterbox/pillarbox
> case, it's about shrinking the reported screen size so that window
> management, clients, etc, all believe that the screen is smaller than
> it is.

So it's up to wayland or compositor to take account of the side band,
including touch controller.
Am I right?

Michael
>
> Cheers,
> Daniel

Re: display band (display area vs real visible area)

[Simon Ser]

The thread is:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/87