15:07 <DemiMarie> Could/should there be a protocol for allowing XWayland to tunnel X11 inside Wayland?

15:07 <DemiMarie> There are a huge number of cases where the lack of ordering between X11 and Wayland events causes bugs which require additional roundtrips to fix.

15:12 <kennylevinsen> I'm not sure how that would even work. x clients talk directly to xwayland - where would the protocol be used?

15:12 <DemiMarie> Between XWayland and the compositor

15:17 <kennylevinsen> so just for the xwm stuff?

15:18 <kennylevinsen> maybe, but all of the xcb stuff would have to support using the tunnel and at that point you could also argue just porting the messages to be a native wayland protocol...

15:19 <emersion> what kind of issues are we talking about here?

15:19 <emersion> WL_SURFACE_ID or something else?

15:21 <MrCooper> emersion: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/818#note_1531201 sounds like you're using "gamescope" as a synonym for "Wayland compositor"? ;)

15:21 <emersion> MrCooper: ah, what i mean is that the code comes from gamescope

15:21 <emersion> since gamescope is DRM master it's fine

15:21 <emersion> but it's not fine for Xwayland

15:22 <DemiMarie> kennylevinsen: Yes, just for the XWM stuff

15:22 <emersion> the code == that whole function, see comment at the top

15:22 <MrCooper> emersion: ah right, makes sense

15:24 <DemiMarie> emersion: All of them 😛

15:24 <DemiMarie> That reminds me: XCB does not perform bounds checking on replies

15:24 <DemiMarie> You need to check that the server actually sent enough bytes (as measured by the length field in the response or event)

15:25 <dottedmag> DemiMarie: please file a bug?

15:25 <DemiMarie> dottedmag: if you mean against XCB, I already did.

15:26 <DemiMarie> It won’t be fixed in the near term, though.

15:26 <daniels> one of the issues with tunneling is that Wayland is very much all about bounded volumes, whereas X11 can generate a potentially infinite amount of spam on the socket, so there's a mismatch there

15:27 <DemiMarie> daniels: then tunnel the other way around?

15:27 <daniels> but apart from that, we're too far down the line for it to be too useful - everyone's typed out the code to deal with the two connections being disjoint, it works well, and unless/until everyone can require a version of Xtrans/XCB/Xwayland/etc which can handle that tunneling, they'd still need to keep that code around too, so practically speaking it would just add more complexity for the foreseeable future

15:28 <DemiMarie> Valid

15:29 <DemiMarie> Anyway, Wayland compositors need to start doing validation of what the X server sends them

15:29 <dottedmag> DemiMarie: I'm sure the authors of compositors will gladly accept patches

15:29 <DemiMarie> This is https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/60 btw

15:30 <dottedmag> Slightly tongue-in-cheek, of course, but compositors-not-trusting-X-servers is a very specific case.

15:30 <emersion> DemiMarie: easier to just disable Xwayland

15:30 <DemiMarie> emersion: yes, which is why I have been pushing so hard about getting Xwayland to *not* require compositor support

15:31 <MrCooper> another possibility is moving the xwm code to a separate process

15:31 <DemiMarie> MrCooper: exactly!

15:31 <DemiMarie> the xwm code should be in a separate process that only has access to standard, unprivileged Wayland protocols

15:32 <emersion> i am not sure this is what MrCooper means

15:32 <MrCooper> indeed it's not

15:33 <DemiMarie> MrCooper: it is what the various sandboxes need

15:33 <DemiMarie> There needs to be a time when a Flatpak that uses XWayland gets no more access than one that does not.

15:35 <DemiMarie> Yes, some apps will break, but I suspect 95+% will not

15:36 <DemiMarie> And those that do could probably run under rootful XWayland anyway.

15:37 <DemiMarie> Yes, it can use compositor support if it exists, but it should be able to fall back to heuristics otherwise.

15:41 <dottedmag> DemiMarie: What about that O'Caml reimplementation? Does it miss anything (apart from being written in O'Caml?)

15:43 <i509VCB> I'm not sure if the intention Demi has is to have that mode be part of xwayland?

16:00 <MrCooper> with dma-buf feedback v4, is it valid for the compositor to list a certain modifier in per-surface feedback but not in the default feedback?

16:03 <DemiMarie> i509vcb: having it part of XWayland would be ideal, yes

16:04 <i509VCB> I believe that was the intention of surface feedback. If you change to full screen and the compositor does direct scanout, the compositor can let you use all modifiers for the display hardware instead of using what is common between multiple gpus because you could move a surface.

16:05 <emersion> MrCooper: compositors must always have a fallback plan

16:06 <emersion> but i guess one could design a compositor where a surface is locked to a specific screen

16:06 <emersion> in which case, on a multi-GPU setup, maybe more modifiers would be available for that surface

16:08 <MrCooper> i509VCB: IME it's more like the default feedback has the same scanout capable modifiers, but also more modifiers which are preferred for rendering, but not scanout capable

16:08 <MrCooper> emersion: makes sense

16:12 <daniels> in the 98% case you'd definitely not do that, because as soon as a notification pops up or the user alt-tabs away, the surface suddenly becomes a void

16:12 <daniels> but in fixed usecases with hardware that would benefit from that, where you 'know' that won't happen, you can do it