@mort this feels like it could be upstreamed. We would need a way to know if a specific display has insets/notches/punch hole cameras, which realistically we’ll need for mobile devices anyway. Once we have a way to define that, we could have Shell avoid drawing in that region.

Maybe we can check in with @agx wrt what Phosh is doing and if we can work on getting that upstream in Shell?

@cassidy @mort When running #phosh just add the notch info to #gmobile and you're done.

For fullscreen apps this needs Wayland protocol support. This is work in progress (but the compositor already uses the same info).

A gnome-shell extension could just pick up the same info.

See https://phosh.mobi/posts/notch-support/

@agx @cassidy Some sort of wayland protocol would be needed for truly fullscreen apps which want to draw around the notch, yeah. But a pretty good alternative would be to lie about the screen dimensions to the wayland client and make it think only the part below the notch/top bar exists, right? I believe that's what macOS does most of the time.

For the moment having #phosh not placing UI elements in the notch area (like the clock) already helps a lot.

We could have the compositor (#phoc) just avoid the notch but we want the app to have a say there (as depending on screen content) it might want to use that area.

I've added https://gitlab.gnome.org/World/Phosh/phoc/-/issues/341 as that looks like a simple thing to add (and we have the information in the compositor already to draw the notch area for debugging purposes).

@mort @agx @cassidy Do you know if the notch info can be expressed in the device tree so there's a canonical place to look it up?

@rmader @mort @cassidy It's not in device tree yet https://lore.kernel.org/dri-devel/f8747f99-0695-5be0-841f-4f72ba5d5da3@connolly.tech/

@agx @mort @cassidy Thanks! @cas do you know if there was any movement on this? The mentioned issue that the DT is not a "userspace configuration store" sounds a bit dubious to me. I mean - nowadays we use it for stuff like camera orientation which is also only useful for userspace.

@rmader @agx @mort @cassidy unfortunately no, i haven't really chased this up, maybe @krzk can chip in.

i just think nobody has really pushed more for it.

@rmader @agx @mort @cassidy @krzk more details on Wayland integration and a verrrry naive proposal i came up with here (although i still think lagrange curves are the most sensible solution to this).

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/87#note_1328045

@rmader @agx @mort @cassidy @cas DT is not for software properties. Camera orientation is a hardware property. I don't know from where you get the impression that properties useful to user-space are no allowed. The user of bindings can be in user-space, firmware, bootloader etc.

@krzk @rmader @agx @cassidy @cas To be fair, properties of the screen are properties of the hardware... we consider resolution appropriate for DT I assume, so why wouldn't details about which regions are physically cut off from the screen? "There are no pixels in this area" is a hardware property isn't it?

@krzk @mort @cassidy @agx @cas Because that's the main reason in the thread why the series wasn't accepted IIUC - https://lore.kernel.org/dri-devel/20210428104403.1e49f270@eldfell/

@rmader @mort @cassidy @agx @cas I do not see any bindings patch there. No comments from DT maintainers either.

@krzk @rmader @mort @cassidy @agx I'd be interested in trying to come with a a more formal proposal

@mort @rmader @agx @cassidy @cas I really have no clue to what you refer (and pasting some links to some long discussions won't help me because none of us has time to read hundreds of pages of possible discussions). For example the cut-off region (inaccessible because of physical layer covering it) for touchscreen got my review and I think it was accepted, so to what do you refer here? Please point me to specific bindings patch where DT maintainers rejected some particular idea. Otherwise I have no clue to what to respond to.

@krzk @mort @cassidy @agx @cas I'm talking about Calebs patch mentioned above by Guido. The second reply - the one from Pekka, which I linked to above - includes the argument "is there not a policy that DT is not a userspace configuration
store?" and concludes with "This seems more like a job for the hypothetical liboutput".

If I understand you correctly you disagree with that policy, correct?

@krzk @mort @cassidy @agx @cas Err, sorry, not Calebs patch but just proposal.

@rmader @mort @cassidy @agx @cas I do not understand that statement, therefore I cannot answer whether I agree or I disagree. I wrote what the DT is for (and what it is not for). To repeat - there is no DT bindings patch in that thread, which I could analyze and respond to.

@rmader @krzk @mort @cassidy @agx @cas I haven’t read the email thread but there isn’t a policy about what component in the stack could use or not the data in a DTB (otherwise why would be exposed through sysfs?), only that must describe HW as @krzk said.

@rmader @krzk @mort @cassidy @agx @cas if you think that can be considered a HW property, then I would say to post a patch to some DT binding schema as suggested and let the DT maintainers to judge. There was no patch from Caleb in that thread AFAICT but just a question.

@rmader @agx @mort @cassidy

https://lore.kernel.org/phone-devel/20231009-caleb-notch-example-v1-1-9e0a43ae233c@linaro.org/