10:20 oeuaoeuoeu: Is is explicitly documented anywhere that, if applicable, only egl and vulkan are allowed to call wl_surface.attach?
10:22 zamundaaa[m]: oeuaoeuoeu: no, because it's not true
10:25 oeuaoeuoeu: The client cannot know if the driver is using explicit sync with the surface. Therefore it cannot attach without first detaching the surface from the driver. (maybe with the exception of a null surface.)
10:26 oeuaoeuoeu: *null buffer
10:27 kennylevinsen: the client is able to attach any importable dmabuf at any time it wants from any source
10:28 kennylevinsen: Not fighting with Vulkan and EGL WSI's is up to the client - if it uses the WSI, it means that it wants mesa to take care of attaching buffers and then the client should not do that
10:28 kennylevinsen: On the other hand, it's free to not use the WSI aspect and just render buffers that it then attaches on its own
10:29 kennylevinsen: (likewise, it might attach buffers from any other location - e.g., buffers from va-api, dmabufs received from other processes, whatever it feels like)
10:29 oeuaoeuoeu: To be clear: by "if applicable" I mean that the client is concurrently using egl or vulkan to attach and commit buffers.
10:31 kennylevinsen: I don't follow what the use-case would be
10:32 kennylevinsen: either way, Wayland doesn't care how or when a process attaches buffers. EGL/Vulkan WSI are just abstractions internal to the process itself, and it's up to the process to make sense of how it wants to manage its surfaces
10:35 oeuaoeuoeu: It does absolutely care if there is a syncobj_surface created by the WSI that the client knows nothing about. There is no way for the client to attach and commit a non-null buffer manually in that situation.
10:35 kennylevinsen: No, it does not care
10:35 kennylevinsen: Being consistent in its communication is up to the client process
10:35 MrCooper: oeuaoeuoeu: as kennylevinsen said, if you use EGL/Vulkan WSI, you can't attach buffers behind its back
10:35 kennylevinsen: its use of mesa is just an implementation detail, and any inconsistencies are just bugs
10:36 MrCooper: oeuaoeuoeu: or even call wl_surface_commit while e.g. eglSwapBuffers may run on another thread
10:37 oeuaoeuoeu: MrCooper: actually that's what I said in my first message until we derailed a bit. My question was if this is explicitly spelled out anywhere so that I can point people to it. Vulkan speaks about this only very abstractly
10:37 kennylevinsen: Well you are in #wayland, so I mainly answered from a wayland perspective :)
10:39 oeuaoeuoeu: Vulkan says: The native window referred to by pCreateInfo->surface must not become associated with a non-Vulkan graphics API surface before all associated Vulkan swapchains have been destroyed.
10:39 MrCooper: I don't know if it's spelled out anywhere, it's an unavoidable consequence of how Wayland requests are submitted though
10:39 kennylevinsen: I suppose that could be written slightly clearer
20:55 Company: zamundaaa[m], emersion: I looked a bit more into how GTK deals with kde_decor and what I said about caring about a system-wide setting was wrong. That setting is no longer exposed as public API in GTK4.
20:56 Company: however, that setting is assumed to be immutable and available at wl_surface sizing time, so there'd be a bunch of work to do to integrate xdg_decor properly
20:59 Company: I do think GTK needs some rework to gdk_wayland_surface_create_wl_surface() anyway so it blocks there until the relevant initial data has arrived (scale factor, preferred image description, etc) so it's all not like that needs massive special work
20:59 Company: but it does need work
21:12 DemiMarie: Company: so one idea I had is a way for clients to indicate that they are drawing their own close buttons, so that the server doesn't need to.
21:12 DemiMarie: The invariant in Qubes OS is that the border must exist, but I don't think it needs to contain any controls.
21:13 Company: I think the buttons are the smaller problem
21:13 DemiMarie: Fair
21:13 DemiMarie: How hard would it be to get shadows sorted out? I'm fine with providing both server-decoration and xdg-decoration.
21:13 Company: I do think though that the binary differentiation between csd/ssd doesn't quite work
21:14 DemiMarie: Not surprised.
21:14 DemiMarie: What would you prefer?
21:14 Company: dunno
21:15 Company: you can make it arbitrarily complex and find ever more corner cases
21:16 DemiMarie: Off-topic: you will be happy to hear that people are working on GPU virtualization, myself included.
21:16 Company: I will be happy once it works ;)
21:17 DemiMarie: MSM renderer is shipping in Chromebooks and used by default. AMDGPU renderer has been merged and i915 renderer is a WIP.
21:17 Company: I like it mostly because I can annoy people with it and ask questions like how explicit sync should work if a VM maximizes one of its apps and the VM host is already maximized so the app in the VM could get direct scanout
21:19 Company: but the buffer must travel from app to vm compositor to vm kernel to vm to gnome-boxes to gtk to host compositor to host kernel
21:19 DemiMarie: Native contexts just expose the host kernel drivers to the guest, so from a compositor or toolkit perspective the app might as well be running on the host.
21:20 DemiMarie: GNOME Boxes actually has a harder time, because it's an extra layer.
21:29 DemiMarie: I’m not sure about VirGL or Venus, but they don't meet my security requirements and have worse performance.
21:30 DemiMarie: I agree that extra complexity is a bad thing.
21:34 Company: I just think it's fun to think about the problem
21:35 Company: and annoy developers with questions about corner cases
21:35 Company: I definitely don't wanna work on it ;)
21:36 Company: otoh, I use it as a litmus test for the APIs people come up with
21:36 Company: if they can deal with recursion, they're pretty good