10:16 MrCooper: swick[m]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_2153728 reminds me of https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/248#note_2117137
10:24 swick[m]: pushing all the gamescope hacks into wayland protocols...
10:24 swick[m]: ah well
11:40 ifreund: why does libwayland use wl_display_get_serial() instead of wl_display_next_serial() for the serial passed to the callback from wl_display.sync?
11:41 pq: that serial stuff is totally bogus altogether, I think
11:41 pq: left-overs from the pre 1.0 days
11:42 ifreund: do you feel the same way about validating input event serials for stuff like setting the primary selection?
11:42 pq: no
11:43 ifreund: I've discovered a client that passes the serial from the wl_callback from wl_display_sync() instead of the input event serial to set_selection :/
11:44 pq: Validating input events serials is a necessary concept to solve some race conditions. Only wl_display_*_serial() is totally questionable if it's ever the right answer.
11:44 pq: ifreund, that sounds like the client is trying to bypass the input serial checks intentionally.
11:45 pq: like if you would write a command line tool for accessing clipboard contents, or something
11:45 ifreund: it's a terminal emulator :/ (kitty)
11:45 pq: which is meant to be impossible for a basic Wayland app
11:47 pq: sounds like a bug
11:48 ifreund: yeah, I'll report it in a minute
11:48 pq: most that I remember of the input serial design is that it is intended to stop clients from doing things when the user has already moved on to do something else and no longer expects the client do stuff
11:49 pq: but I don't think I've ever known how exactly compositors are supposed to manage the serials to make that work correctly
11:50 pq: I have a vague recollection that the wl_display_*_serial() API was supposed to help, but in practice found to be lacking because you'd need many different valid serials at the same time for different things.
11:50 pq: maybe even many different serial counters, I'm not sure
11:51 ifreund: wlroots has a ring buffer of recent serials and does best-effort validation that seems quite effective in practice
11:51 pq: that's nice
11:51 ifreund: and only input event serials are stored in the ring buffer
11:51 ifreund: it was certainly effective enough to catch kitty's bug here
11:52 pq: given a compositor likely needs to keep track of multiple valid serials, passing any serial in the wl_display.sync reply is utterly useless.
11:52 pq: besides, if clients could use wl_display.sync to get the latest valid serial any time, that would thwart the whole idea why input serials exist.
11:52 ifreund: yeah, it's asking for misuse
11:53 pq: so at the very minimum, we should make it clear that input serials are not in any way related to sync serials
11:56 pq: even better would be to actually document how serials are supposed to work both sides
12:06 ifreund: https://github.com/kovidgoyal/kitty/issues/6785
15:43 Guest5651: pq: Serial numbers aren’t access tokens as the entropy is too low. I don’t see a problem with being able to get the latest valid serial, but often the answer should be that no such serial exists.