One of the most frustrating thing about #Asahi #Linux: #GNOME is so *incredibly* close to working perfectly witch a notch. Literally all you need to do is to increase the size of the top bar size a bit and move the calendar/notifications menu to the right and it's perfect.
But GNOME doesn't have those options, you have to use extensions. And changing the top bar size from an extension is buggy and breaks in weird ways after suspend.
I actually started planning a blog post about how well GNOME can work with a notch because its design happens to be an almost perfect match already. I stopped when I started having this issue.
I tried finding ways to work around it. IIRC, if I modified the bar height through changing the default theme's CSS, it would work fine. But the default theme's CSS file is bundled in a .gresource file, and it gets overwritten when GNOME updates, so it wasn't practical.
@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?
@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.
@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 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?
@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.
@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.