02:16 Riolku: Hello! New to wayland protocols, is it correct that after committing a buffer, a client should not update the mapped contents? And thus that to do updates a new buffer is needed?
02:17 Riolku: Does it then make sense to alternate between a current and pending buffer on the client side, just like on the server? Like after attaching a new buffer, the old one can be reused?
02:41 jadahl: Riolku: when you commit a buffer, you shouldn't manipulate its content until it's "released" (wl_buffer.release). when you prepare the content of the next frame, you should use another buffer, and commit the new buffer, i.e. "double buffering"
03:30 ascent12: Riolku: The compositor can hold onto your buffer longer than "expected", even if you've committed a different one, so you must wait for the release event before you reuse any buffers.
03:31 Riolku: i might need three buffers then, right? If buffer A hasnt been released, and I want to prepare a new frame after committing C
03:33 ascent12: I think in the theoretical worst case, you need 4, but 3 is more than good enough most of the time. At least 4 is the number mesa uses for e.g. vulkan swapchains.
03:34 Riolku: Wait... why four?
03:36 ascent12: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/wsi/wsi_common_wayland.c?ref_type=heads#L1030-1035
03:36 ascent12: I don't know how much the 4th gets used in practice, especially if the client is actually waiting for wl_surface.frame
03:36 ascent12: I don't think a wl_shm would ever need 4 either
03:37 ascent12: wl_shm buffer*
03:37 Riolku: related question - do apps generally create one shm pool per buffer? that seems simplest
03:38 ascent12: Yeah there is nothing wrong with doing that.
03:39 Riolku: I suppose more complex applications can do freelist or proper allocaton stuff on a large pool?
03:43 ascent12: Probably more effort than it's worth to go too complex here. The difference between having 1 or 2/3 shared memory things open is negligible in the grand scheme of things.
03:43 ascent12: But you could put all of your buffers into the same shared memory if you really wanted to.
03:45 ascent12: Depending on how the compositor is implemented, they may release your wl_shm buffer immediately, because they copy it to their own GPU buffers straight away.
03:45 ascent12: So you could potentially only need 1
03:46 ascent12: But that's not really the best assumption to make, and a client should be prepared to make more if needed.
04:03 Riolku: Makes sense, Ill definitely just make pools as needed
04:03 Riolku: ty
06:53 kennylevinsen: Riolku any1: 4 buffers can happen during direct scanout: One buffer currently displayed by drm, one committed to drm to replace it, one held by the compositor as the next to be committed to drm, and one used by the client to draw
06:57 kennylevinsen: The reason being that we cannot replace or amend a drm commit, so if new buffers come afterwards - too bad, they have to wait
07:00 kennylevinsen: During composition it is 3 buffers: One buffer held by the compositor to composite the current screen from, one held by the compositor to replace it, and one used by the client to draw
07:03 kennylevinsen: But they are worst-case numbers. For shm specifically there is even an optimization where some compositors release the buffer early so the client can do with 1
08:13 wlb: weston Merge request !1371 opened by Marius Vlad (mvlad) neatvnc.wrap: Update to neatvnc 0.7.0 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1371 [Backend-PipeWire]
08:19 wlb: weston Issue #821 closed \o/ (backend-drm: client view leaves remnant in rendered output after moving it to plane https://gitlab.freedesktop.org/wayland/weston/-/issues/821)
08:19 wlb: weston/main: Derek Foreman * backend-drm: Fix visibility calculation https://gitlab.freedesktop.org/wayland/weston/commit/209b7eb56a40 libweston/compositor.c
08:19 wlb: weston Merge request !1369 merged \o/ (backend-drm: Fix visibility calculation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1369)
08:23 wlb: weston/main: Derek Foreman * libweston: fix output clamp helper https://gitlab.freedesktop.org/wayland/weston/commit/e49294b901b7 libweston/compositor.c
08:24 wlb: weston Merge request !1368 merged \o/ (libweston: fix output clamp helper https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1368)
08:31 wlb: wayland Merge request !340 opened by YaNing Lu (luyn) protocol: add wl_pointer.button_position event https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/340
08:33 soreau: Often times, there are unused listener interface functions in the (client) code. Is there a way that the unused function pointers can be set to NULL and have the scanner do a NULL check instead of forcing definition of each?
08:34 emersion: that would be nice
08:50 soreau: Actually not the scanner, but libwayland. It seems it's as simple as http://ix.io/4IyH
08:50 soreau: emersion: any 'gotchas' you can think of besides this patch alone?
08:51 emersion: need to handle resource cleanup
08:51 emersion: for FDs and server-side objects, at least
08:51 soreau: should it call wl_closure_clear_fds(closure); before retruning?
08:52 soreau: I mean would that be enough to do what you're saying
09:04 wlb: wayland Merge request !341 opened by Scott Moreau (oreaus) server: allow null opcodes https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/341
09:22 soreau: made it so it only allows NULL for clients, to side step having to destroy any new_ids
09:23 emersion: what do you mean by side step?
09:25 soreau: i.e. still use the same abort for servers but not clients
09:27 emersion: clients need to handle new ids as well
09:27 soreau: oh, I misunderstood the comments then
10:05 pq: soreau, emersion, I can see why it might seem convenient to be able to use NULL as an event handler when you don't care about it. I am opposed though, because the empty functions have documentary value, and using NULL is not simple for libwayland in the corner cases of fd and new_id arguments.
10:06 pq: Sure, libwayland-client can just close an fd, but the new_id essentially explodes into the full "automatic implementation of inert objects" problem.
10:07 pq: What if the new_id object immediately delivers an event with a new_id.
10:08 pq: libwayland-client would not be able to automatically destroy all theoretically existing objects either, because the destroy sequence could be more complex than a simple destructor call.
10:08 pq: not all interfaces even have an explicit destructor
10:09 pq: All that makes it really hard to see how the libwayland-client implementation could be safe.
10:10 soreau: I ran some code using this with mode set to NULL https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/protocol/wlr-output-management-unstable-v1.xml?ref_type=heads#L204 under valgrind and it came back clean with 0 errors and the same output as without the patch, using -s --leak-check=full --show-leak-kinds=all, though I'm not sure if this excersises the case you're talking about
10:10 pq: OTOH, an explicit implementation in the caller of libwayland-client is always specific to a particular interface and is therefore easy to review to be always correct.
10:11 soreau: but if you do not want to entertain this, please close the MR with a comment
10:11 pq: soreau, try the same with an event carrying a new_id.
10:12 soreau: pq: does this event not carry a new_id?
10:12 pq: then, with the new_id using an interface that has no desctructor request but gets destroyed by other means.
10:12 pq: it does
10:14 pq: you can craft tests that show that no *existing* protocol interface is able to break your auto-ignore-destroy logic, but I believe I can always craft a new protocol interface that will break it.
10:15 soreau: clearly, this would be a waste of time
10:15 pq: yes
11:33 DemiMarie: How do compositors with server-side decorations deal with clients that commit with a different size than expected?
11:36 pq: I'm happy to see the proposal and the review discussion on the xdg-alignment protocol.
11:36 pq: DemiMarie, simply draw decors for the actual size?
11:37 pq: either the protocol allows a different size, which means the compositor deals with it, or protocol doesn't which leads to disconnection with a protocol error.
11:48 DemiMarie: pq d_ed: question is *how* to deal with it, considering that I am writing a seamless compositor with a backend that expects me to submit a buffer with the exact size that it requested.
11:53 kennylevinsen: DemiMarie: Server-side decorations are drawn around whatever buffer the client commits
11:53 kennylevinsen: as the client decides the size of the window whenever it commits a buffer
11:54 DemiMarie: d_ed: The protocol I am using for drawing expects that its own idea of the window size is authoritative.
11:54 kennylevinsen: I'm not seeing d_ed - IRC auth issue + matrix bridge shenanigans again?
11:55 DemiMarie: Probably
11:55 DemiMarie: d_ed: you need to reauth
11:56 kennylevinsen: DemiMarie: Your own protocol can dictate whatever behavior you want, including requiring implementing clients to strictly adhere upon an ack-ed configure or similar
11:56 kennylevinsen: but that will not apply to "normal" wayland clients using e.g. xdg-shell
11:56 DemiMarie: kennylevinsen: I don’t have control of either side here.
11:57 DemiMarie: I’m trying to figure out how best to deal with this (bad) situation.
11:57 kennylevinsen: In that case you must accept that the client dictates the window size and have the SSD conform to it
11:58 kennylevinsen: When tiling, sway clips windows if the containiner is smaller than the window can/will render, and centers the content when larger, but that is bad UX for a floating window
11:58 kennylevinsen: *container
11:59 wlb: wayland Merge request !341 closed (server: allow null opcodes for client invocations)
12:01 DemiMarie: kennylevinsen: This is a rootless compositor, and the backend protocol is itself backed by an X11 WM that can and will impose whatever policies it wants.
12:01 DemiMarie: Would it be best to tell the client that it is tiled?
12:01 wlb: wayland Issue #160 closed \o/ (allow NULL callbacks in listeners https://gitlab.freedesktop.org/wayland/wayland/-/issues/160)
12:04 kennylevinsen: DemiMarie: only if the client *is* tiled
12:05 pq: DemiMarie, if Wayland says window size can be any, and your own API requires a specific size, then I'm sorry. clip/scale/stretch/pad...
12:05 DemiMarie: kennylevinsen: It may or may not be (I don’t know that), but it is the only way I can think of to prevent infinite resize loops.
12:05 pq: nothing to do with decorations, too
12:05 DemiMarie: pq: yeah, the long-term solution is cross-VM Wayland but that is a *much* larger project.
12:07 pq: Since clipping may lose vital window content, I would probably do an aspect-ratio-preserving scaling with padding.
12:08 DemiMarie: And yeah, nothing to do with decorations. It just means that writing a conformant rootless compositor with an X11 backend is not possible.
12:08 DemiMarie: Not without the risk of infinite resize loops or ugly heuristics to break them.
12:09 pq: why is it not possible? Wayland client with X11 WM seems like the best arrangement if you have to cross-plant a window.
12:09 pq: X11 apps can already disagree with the X11 WM, too
12:09 kennylevinsen: DemiMarie: Even with the states that set requirements to dimensions (e.g., maximized and fullscreen), these are only followed when acked so there can be an artbirary number of frames with a different dimension
12:10 pq: the result is clip / pad with garbage, so at least when you can scale + pad, you are already doing better than X11
12:15 DemiMarie: pq: because client-initiated resizes need to work (think Ctrl-+ in various terminal emulators) and I need to somehow distinguish between “client resized window” and “client is responding to server-initiated resize”.
12:23 kennylevinsen: sway used to do this IIRC - it's an issue with X clients primarily. The best solution is send e.g. configure events on drag-to-resize, but always rendering the at any time client-submitted dimensions
12:23 kennylevinsen: that deals better with clients that have, say, aspect-ratio restrictions
12:32 pq: DemiMarie, what's the conflict or problem there? Why do you even need to make that difference?
12:33 pq: DemiMarie, although, with Wayland ack_configure, you can know what is a reaction to a configure event. It just may be combined with client spontaneous resize.
12:47 luyn: pq: Thank you for responding to my proposal to add wl_pointer.button_position
12:49 pq: luyn, you're welcome.
12:52 luyn: This problem can also be reproduced not only on kwin, but also on other compositor. I think button_position is very necessary to add. It is unclear whether there are other scenarios where the position is not updated.
13:13 pq: luyn, no, I think it's the compositors that just didn't realize what to do when the window moves under the pointer. After all, it takes great care to even observe the problem by not accidentally moving the mouse one bit.
13:13 DemiMarie: pq: the problem is that I have never written a compositor before, and was not sure what to do.
13:14 DemiMarie: pq kennylevinsen: thanks for the help!
13:14 pq: DemiMarie, alright, in that case kennylevinsen said what's good to do. :-)
13:15 pq: as I'm accustomed to the protocol asynchronicity, it's kind of obvious to me that the compositor always paints what it got, not what it asked for.
13:16 pq: the same applies to window states
13:16 pq: if the compositor tells the client window to go from windowed to maximized, the compositor will keep on drawing it windowed until the client acks the maximized state
13:35 luyn: pq: Thank you. Do you have any suggestions for this problem
14:02 pq: luyn, yeah, it's in that reply I left in your MR.
16:07 Riolku: can i attach one buffer to multiple surfaces? If so, do I have to refcount the release events?
16:10 Riolku: ah, the docs say I shouldnt do this, and should instead create multiple buffers from the same backing storage, because release events are undefined if i reuse a buffer
16:49 wlb: wayland-protocols Merge request !250 opened by Sebastian Wick (swick) build: move unstable protocols to staging https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/250
18:41 emersion: Riolku: there is a MR to fix that and have per-attach release
18:41 emersion: I'd be interested to know your use-case, the only thing the MR needs is more client impl
18:43 Riolku: Im writing a simple background display client, and want to attach the same buffer to multiple outputs if they have the same resolutions
18:51 emersion: sounds great use-case
18:52 emersion: Riolku: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/137
18:56 Riolku: awesome, Ill try to comment on this after I get further on my project
19:01 Riolku: Is it considered bad practice to not destroy objects like WlShm on disconnect?
19:03 emersion: it doesn't really matter
19:04 emersion: it does make it more difficult to use leak detectors
19:05 emersion: but apart from that, no real difference if you're going to exit
19:05 Riolku: makes sense ty
21:09 wlb: wayland-protocols Merge request !251 opened by Sebastian Wick (swick) linux-dmabuf: mark as stable, v2 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/251