01:16 <DemiMarieObenour[m]> emersion kennylevinsen: for the unprivileged XWayland implementation, would you still be interested if the code was written in Rust as an X11 compositing manager, or would you prefer that it be written in C?

04:25 <wlb> weston Merge request !713 opened by () Implement xdg-decoration-unstable-v1 support for toytoolkit https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/713

06:41 <wlb> weston Issue #555 opened by () kiosk-shell/kiosk-shell.c 410:Does it need to process the other situations? https://gitlab.freedesktop.org/wayland/weston/-/issues/555

07:04 <kennylevinsen> DemiMarieObenour[m]: it would always be interesting, but it would reach a wider audience in C for now.

07:05 <DemiMarieObenour[m]> How much wider? Factor of 1.1 or factor of 5?

07:06 <DemiMarieObenour[m]> to be fair, this code mostly doesn’t deal with untrusted data and (unlike XWayland) doesn’t have any special privileges, so while I would prefer Rust, I would be okay with C if that dramatically increased its reach

07:08 <kennylevinsen> You're asking for more data than I have available, but as personal anecdote my C projects always get far more popular by factor 5-10 than my Rust ones. C is also easier to package...

07:12 <DemiMarieObenour[m]> Factor of 5-10 is definitely enough to tip the balance if security is not critical, as is the case here. If this were a server processing untrusted network traffic Rust would be a far better choice.

07:30 <DemiMarieObenour[m]> Should this be a nested Wayland compositor backed by XWayland, or a custom driver for X11 that uses Wayland for input and rendering? The latter offers potential performance advantages and avoids having to spawn a subprocess, but the former seems far simpler to implement.

07:42 <ofourdan> I am not sure I understand, what's the problem you're trying to solve and what priviledge does Xwayland have? afaik, Xwayland is a standard Wayland client, it doesn't have any specific priviledge.

07:43 <raphi7163> xwayland has special privileges, it can force grab the entire keyboard using zwp_xwayland_keyboard_grab_manager

07:44 <ofourdan> raphi7163: no it cannot if the compositor doesn't implement that

07:44 <ofourdan> it is not mandatory in any way

07:45 <raphi7163> true

07:49 <DemiMarieObenour[m]> XWayland also requires the compositor to give it information ordinary Wayland clients do not have, so it doesn’t work well in rootless nested compositor scenarios.

07:49 <ofourdan> can you be more specific, what information?

07:50 <DemiMarieObenour[m]> Absolute window position for one. XWayland also needs to be able to set absolute window position.

07:50 <ofourdan> no

07:51 <ofourdan> Xwayland doesn't, at all

07:51 <ofourdan> Xwayland (or X11 clients, rather) cannot place its windows either, this is purely between the X11 client, the X11 window manager and the X11 compositor - so if the problem is the placement of O-R windows, it's just a matter of /fixing/ the X11 compositor + X11 window manager not to honor placement - In X11, the window manager always have the final word, it's just policy

07:51 <ofourdan> there is no wayland protocol th place Xwayland windows

07:56 <pq> I believe XWM moving O-R windows may lead to fighting from X11 perspective as the XWM is not in the loop to position those in X11, but to the end user that doesn't show up, because the Wayland compositor draws the X11 windows where-ever the Wayland compositor wants them.

07:57 <pq> I suppose that might lead to broken application logic when the O-R is not where the app tried to force it.

07:59 <ofourdan> right, but it's just policy, one may want to break some behavior in x11 apps to improve security

08:00 <pq> sure

08:00 <ofourdan> my point being, this is not Xwayland having priviledge, it's X11 being more permissive so it should be /fixable/ without rewriting another X11 server in the compositor

08:00 <pq> yup

08:01 <pq> and without going back to the xwayland-as-DDX design

08:17 <DemiMarieObenour[m]> That still requires the Wayland compositor to support XWayland, though. In the use-cases I am wanting, that isn’t an option: consider the case of a sandboxed Flatpak app that only has access to the Wayland socket and must bring its own X server to run legacy X programs.

08:18 <kennylevinsen> ofourdan: yeah, rewriting an X11 server would be too much work - for me the curiosity was regarding an xwayland that did not use xwm and just acted as a plan wayland client. Would still be Xorg.

08:20 <kennylevinsen> (although re: xwm policy, I don't think one really has much choice if one wants decent compatibility. X11 clients seem... fragile. And if compatibility can be sacrificed for policy, then Xwayland can just be omitted altogether. :P)

08:20 <DemiMarieObenour[m]> my idea was to actually have an xwm, but for it to be separate from the Wayland compositor.

08:21 <kennylevinsen> that's an implementation detail from my perspective - what the compositor needs to support is the interesting aspect

08:22 <DemiMarieObenour[m]> indeed

08:23 <DemiMarieObenour[m]> kennylevinsen: so my goal is to do what Wine on Wayland does: work (with no compromises) for all decently behaved X11 clients, and be at least usable for the vast majority of the rest. My understanding is that most X11 clients either (1) use open source toolkits that conform to EWMH or (2) are games that just do everything themselves.

08:26 <kennylevinsen> 2 isn't reserved for games. There are quite a few plain x11 clients, as well as toolkits that may only have <10 users. Whether things are conformant, idk. I would suspect it's more a matter of relying on whatever behavior standard wm's happened to implement, rather than what was promised.

08:26 <kennylevinsen> (Things using major toolkits would likely support wayland anyway)

08:28 <DemiMarieObenour[m]> That is true. That said, I imagine the situation is no worse than in Windows-land. If Wine can map the Windows API to Wayland we should be able to do the same with X11.

08:31 <kennylevinsen> True - although to be fair, wine does appear to be a continuous struggle

08:32 <DemiMarieObenour[m]> Their heuristics are very simple, though.

08:33 <wlb> weston Merge request !714 opened by () gl-renderer: Take into account viewport when choosing filtering https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/714

08:57 <pq> DemiMarieObenour[m], let's see how the wine-wayland backend has evolved 2 years after it has been merged upstream. I bet it won't be anywhere near simple.

09:00 <pq> it's the same with native X11 window managers - they take a decade of iterative development to become able to accommodate native X11 apps.

09:01 <ofourdan> true

09:02 <pq> ...and that is without any complications that having Wayland in the picture will bring.

11:44 <daniels> kennylevinsen: the Wine Wayland backend is being upstreamed, it's just got a very long list of requirements from upstream before they'll consider it

11:45 <kennylevinsen> daniels: :D

19:54 <wlb> wayland Merge request !186 opened by () Draft: add wl_client_get_pidfd and wl_client_get_user_dat/wl_client_set_user_dat https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/186

20:10 <wlb> weston Merge request !715 opened by () Draft: race free client identification https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/715

20:12 <swick> questionable quality but at least it's out now and can be used to convince kernel folks that SO_PEERPIDFD is actually a good idea

22:25 <DemiMarieObenour[m]> swick: There is actually a good alternative: have the client send a pidfd and then its PID, then check that the two match.

22:28 <DemiMarieObenour[m]> The check can be done by checking that the provided FD (for `/proc/$PID`) and an FD to the `/proc/$PID` the server opened have the same device and inode numbers. The provided FD cannot belong to a reused PID because of causality. Sadly that only works if they share a `/proc`.

22:30 <wlb> weston Merge request !716 opened by () xwayland: Fix copy and paste error https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/716