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 at fooishbar.org> wrote:
>
> Hi,
>
> On Tue, 21 Mar 2023 at 12:08, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> > On Tue, 21 Mar 2023, Daniel Stone <daniel at 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