03:49 <wlb> wayland Issue #244 opened by () Can't get a valid working area https://gitlab.freedesktop.org/wayland/wayland/-/issues/244

08:16 <pq> DemiMarieObenour[m], that completely depends on what extensions the compositor supports. Any extension can add more stuff to be latched on wl_surface.commit. E.g. wp_viewporter does.

08:17 <pq> DemiMarieObenour[m], I think xdg-shell adds a "huge" amount of window management state as well. And don't forget sub-surfaces, where one commit can gate another wl_surface.

08:18 <pq> DemiMarieObenour[m], IIRC the term is "double buffered state".

10:21 <pq> I created a new Weston Gitlab label "new Linux UABI" so we can tag MRs that might be blocking and be blocked by kernel patches.

13:45 <DemiMarieObenour[m]> pq: so my question is more what is needed from the underlying backend. X11 allows swapping buffers atomically, which isn’t sufficient.

13:50 <kennylevinsen> It's important to mention that you're doing a "rootless" compositor. A normal backend only shows buffers, so atomic swap is all it takes.

13:53 <kennylevinsen> For a "rootless" setup, it depends. If you don't composite anything but just forward all surfaces, your parent technically needs to be as strict or stricter than Wayland on all accounts. Requires for you to check the protocols you'd like to offer.

13:55 <kennylevinsen> But it'll sum up to being able to atomically update surface type, content, geometries and relationships.

13:55 <kennylevinsen> (with me considering transforms part of geometry/content above)

14:06 <DemiMarieObenour[m]> In my case, the current plan is to composit everything but `xdg_toplevel` surfaces. Since only `xdg_toplevel` surfaces are being forwarded, the “type” requirement is trivial, as all surfaces are the same type. Any protocol worth its salt (even X11!) can handle atomic content updates, which leaves geometry and relationships. What relationships do I need to worry about?

14:07 <DemiMarieObenour[m]> Also, could geometry be handled by some sort of communication between the GUI daemon and the X composite manager?

14:18 <kennylevinsen> You'll have to composite the top-level too whenever you need to composite anything. Relationships in the way of popup and subsurface position and rendering are automatically taken care of with that approach. There's also top-level with parents though, which are normally positioned floating over their parents but otherwise a normal top-level.

14:19 <kennylevinsen> As for the other part, idk. Not an X expert. As long as the window's size, including during resize, always matches the size of the last committed buffer, you're good.

14:20 <DemiMarieObenour[m]> kennylevinsen: Darn. There is literally no way I can implement this with my backend 😞

14:21 <DemiMarieObenour[m]> I might be able to use `transient_for` but am not sure.

14:25 <kennylevinsen> But what you need really depends on your exact implementation. Pretty much everything is double buffered in Wayland, and pretty much nothing is in X.

14:29 <DemiMarieObenour[m]> I have already accepted that my initial implementation will be non-conforming, though things should usually work out as I will be dumping all of the state changes to the backend in a single burst. That said, there are two parts that are *really* tricky:

14:29 <DemiMarieObenour[m]> 1. I need to minimize the ways that a malicious client could attack the trunk compositor the GUI daemon is using.

14:29 <DemiMarieObenour[m]> 2. Once the GUI daemon becomes a Wayland client (planned), I won’t be able to do whole-qube screenshots without interactng with the trunk compositor. That in turn runs the risk that a bug in the trunk compositor could leak data across qubes, which would be really bad.

14:29 <DemiMarieObenour[m]> The second part is why I requested a “where am I?” protocol.

14:32 <kennylevinsen> You can have special purpose local protocols btw. Nothing unusual about that, and perfectly sensible for internal talk between your main and sub compositors that do not fit "normal" client needs.

14:33 <kennylevinsen> Using that you're free to expose whatever you want/feel comfortable with given your own security boundary definitions

14:47 <DemiMarieObenour[m]> That is probably the way to go, if more than a bit unfortunate. Qubes OS supports multiple desktop environments, and having to patch all of them is something the Qubes OS team would prefer to avoid.

14:53 <kennylevinsen> But isn't the primary and sub compositors managed by qubes?

14:58 <DemiMarieObenour[m]> One goal is to move the GUI out of dom0, at which point being able to use distribution-provided (Fedora/Debian/etc) packages for the primary compositor would be very useful.

17:01 <wlb> weston/main: Emmanuel Gil Peyrot * simple-touch: Use true/false instead of 1/0 for bool type https://gitlab.freedesktop.org/wayland/weston/commit/b94219adeb0b clients/simple-touch.c

17:01 <wlb> weston/main: Emmanuel Gil Peyrot * simple-touch: Remove unused include https://gitlab.freedesktop.org/wayland/weston/commit/b596342e37d4 clients/simple-touch.c

17:01 <wlb> weston/main: Emmanuel Gil Peyrot * simple-touch: Exit on xdg_toplevel::close https://gitlab.freedesktop.org/wayland/weston/commit/152405b8f91d clients/simple-touch.c

17:01 <wlb> weston Merge request !704 merged \o/ (simple-touch: Exit on xdg_toplevel::close https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/704)

17:23 <wlb> weston Merge request !705 opened by () desktop-shell: Don't crash on when attemping to switch https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/705

17:26 <wlb> weston Merge request !706 opened by () libweston: Don't enable debug keybindings by default https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/706