display band (display area vs real visible area)

Daniel Stone daniel at fooishbar.org
Tue Mar 21 12:15:12 UTC 2023


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.

Cheers,
Daniel


More information about the dri-devel mailing list