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?

@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.

@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

@rmader @mort @cassidy @cas
whatever (hopefully) ends up in the kernel we need a way to provide the information via userspace too for
- overrides / non dt-devices
- tests (where you e.g. want to check phosh's layouting for different notch positions)

That's why it ended up in gmobile (https://gitlab.gnome.org/World/Phosh/gmobile). If it comes from DT or viia drm properties too we'll pick it up there as well for compositors and shells to make use of it.

@rmader @agx @mort @cassidy

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

@rmader @agx @cassidy Devicetree could work for ARM machines, which are probably the main use case here, but it wouldn't surprise me *that* much if Dell comes out with an amd64 laptop with a camera notch/hole in the future. That means we need a place to store this sort of info on devices without devicetree as well.

Though that could be fixed by exposing these parameters in GNOME settings and just using the devicetree on arm systems to set the initial configuration.