00:52i509vcb: What should happen if a wl_surface.commit is performed with no role or an incomplete role? For no role, there is no documented expected behavior. For incomplete roles (such as xdg_surface without a xdg_toplevel or xdg_popup), the role does not describe the expected behavior either
01:00i509vcb: For now I've just decided to ignore the commit if those incomplete or no role cases come up (I think cursor images are an exception here as those do assign a role).
08:43wlb: weston Issue #811 closed \o/ (Segfault when opening a program by pressing a stylus on a launcher https://gitlab.freedesktop.org/wayland/weston/-/issues/811)
08:43wlb: weston/main: Wujian Sun * libweston-desktop: Fix weston crash when lost the shsurf https://gitlab.freedesktop.org/wayland/weston/commit/042d02f42221 libweston/desktop/surface.c
08:43wlb: weston Merge request !1447 merged \o/ (libweston-desktop: Fix weston crash when lost the shsurf https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1447)
09:49pq: i509vcb, my expectation is that the wl_surface.commit does the latching as specified. If the client later gives a proper role to the surface, then the role spec usually says what kind of existing state would be a protocol error.
11:55ifreund: well, this might be the most broken example of a client's configure/ack_configure/commit handling I've come across yet: https://github.com/riverwm/river/issues/997#issuecomment-1961191983
11:55wlb: weston/main: Leandro Ribeiro * libweston: create/destroy color profile id generator in a safe point https://gitlab.freedesktop.org/wayland/weston/commit/ffe08c43449b libweston/compositor.c
11:55wlb: weston Merge request !1465 merged \o/ (Create/destroy color profile id generator in a safe point https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1465)
11:56emersion: Wezterm is known to have its maintainer dislike wayland
11:56emersion: oh, no, nevermind, i'm mixing it up with another terminal emulator
11:57emersion: ("wayland sucks, so i'm still going to support it, but will not try to understand it")
11:58ifreund: I think my favorite part of the log is the commit with old dimensions, xdg_toplevel.set_window_geometry with new dimensions, commit again without attaching new buffer part
11:58ifreund: which are commits 2 and 3 after acking the configure
11:59YaLTeR[m]: my favorite part is how it waits for a 0 configure at startup
11:59ifreund: hah, I didn't notice that because my compositor still sends 0 configures as the first one (shame on me I know, I need one more wlroots release before I can fix it though because of reasons)
12:00Company: finally someone is fuzzing the compositors properly
12:02vyivel: ifreund: if you want to "fix" it right now, wl_event_source_remove(wlr_xdg_surface.configure_idle) on initial_commit=true
12:02ifreund: oh true, that would work
12:05Company: ifreund: usually that happens when people have an old codebase, that doesn't have a "commit" stage
12:06Company: the initial port is always one where every action that requires a commit is immediately committed
12:06Company: seems to be what's going on here
12:06Company: set_title(); commit();
12:07Company: especially with X11, because that's how X11 works - everything is instantly "committed"
12:07pq: is there a good write-up about "don't immediately commit every single action"?
12:07ifreund: Company: yeah, I definitely see how it could happen. The bug is probably acking the configure right away instead of waiting until a buffer of the correct size is ready
12:07vyivel: (set_title isn't even double-buffered)
12:08pq: flushing seems to be similar, except it's not fundamentally harmful.
12:08ifreund: Compositors should be able to deal with this misbehavior just fine of course, I just wish the client authors realized that they are sacrificing frame perfection
12:08pq: no, there are some cases that are defined to be protocol errors
12:09pq: mismatching maximized size comes to mind
12:09ifreund: right, though does anyone enforce that?
12:09pq: I would think Weston does.
12:10vyivel: weston does indeed
12:10vyivel: and nothing else iirc
12:10pq: everyone certainly should, because it says so in the spec
12:10ifreund: It also says that clients cannot commit a larger buffer than requested while the resizing state is set
12:11ifreund: but mpv does so in order to maintain its aspect ration and I think it's right to do so
12:11ifreund: ideally there would be some way in the protocol to communicate that aspect ratio stuff in a policy over mechanism way but there isn't
12:12pq: why not constrain by the more restrcitive dimension instead of exceeding given size?
12:12ifreund: because you couldn't make it bigger then unless you manange to keep your curson on exactly the right line while resizing
12:12emersion: pq, enforcing would break a whole bunch of clients
12:13pq: sure you could make it bigger, it would just fit inside the rectangle whose one corner is the pointer position
12:13emersion: pq, also unclear what a client with maximum size set should do when the compositor configures it maximized with a larger size
12:13pq: apps should be broken fast and early, so that all the corner cases can be found and decided what to do about them
12:14emersion: yeah it's just a bit late now
12:14pq: does it need a protocol spec change, or is it an app bug
12:14YaLTeR[m]: pq: You can't with one sided resizing
12:14pq: just keep it in mind for every new feature coming from now on, at least
12:15pq: YaLTeR[m], that's true.
12:16ifreund: pq: Yeah I totally agree with the protocol errors for any misbehavior take, it just needs to be enforced from day 1 to be effective
12:16pq: the answer is to rethink the spec, not ignore the spec
12:17emersion: easy to say :)
12:18YaLTeR[m]: pq: the problem with killing on maximized mismatch is not so much that it wasn't enforced, but more that it's also a very rare edge case, so even if all compositors enforced it, the client devs wouldn't hit it on their setup
12:18pq: immediate pain vs. future pain
12:18Company: pq: the commit stuff is one of the worst things about Wayland anyway
12:19pq: Company, you can stick to X11, it's fine.
12:19Company: pq: because app devs should never commit ever, because that's the job of libGL
12:19pq: yeah, and apps who don't use libGL...
12:19Company: so you don't just need to reorganize your whole backend, you also need to wrap it around your GL usage
12:19YaLTeR[m]: So at this point it's better to just work around in the least disruptive way (i.e. clip on size mismatch instead of killing), similar to how in a compositor you want early returns on programming bugs instead of assert
12:20Company: YaLTeR[m]: render pink!
12:20ifreund: oh no, I want asserts in my compositor
12:20Company: people hate that and file bugs, but it doesn't kill any apps
12:20ifreund: any high reliablity code should be full of asserts IMO
12:20pq: we do fill Weston with asserts
12:20Company: YaLTeR[m]: see also: gtk4paintablesink shader nodes ;)
12:21YaLTeR[m]: better than killing the app
12:21ifreund: Company: I actually love that idea :D
12:21Company: ifreund: https://gitlab.gnome.org/GNOME/gtk/-/issues/6325
12:22kchibisov: set_title doesn't require commit if it matters.
12:22kchibisov: And some other stuff also doesn't.
12:22Company: it gets people to actively resolve the issue and it's less finger-pointing than crashers
12:23Company: it's harder to figure out what's wrong though if its smallish things
12:23Company: like a single pink frame when maximizing
12:23Company: because there's no trace, unless you also log something about it
12:23YaLTeR[m]: if only the half decent solution didn't also involve 3 different ways across 3 different gtk version ranges
12:23pq: How about that nag protocol extension I've dreamed about a few times?
12:24davidre: The compositor could paint "This client is buggy, go harass its developer" in the corner of the window :P
12:24pq: and mentioned here
12:24Company: YaLTeR[m]: there's multiple bugs in there, and at least the GTK ones are fixed now - I think GStreamer still doesn't tell that the buffer is opaque and that whole mess is unnecessary :p
12:24davidre: pq What's the nag extesion?
12:25pq: a tiny protocol extension that compositors could use to send messages into clients' logs, like "you're doing it wrong, but I'm covering for you"
12:25ifreund: I would implement a nag protocol for the broken commit handling stuff
12:25ifreund: currently I just log a shame message: https://github.com/riverwm/river/blob/f2b6893b00a089810c94a86fa2c8df1b823fcaf4/river/XdgToplevel.zig#L363
12:25kchibisov: ifreund: wezterm is generally broken and given that the project is overly complex noone will bother fixing it, given that all the relevant fixes stuff are provided for like 2 year.s
12:26kchibisov: We still have to issue patch releases in sctk for old broken versions just to somehow keep wezterm alive.
12:26ifreund: kchibisov: yeah, pretty much what I thought
12:26YaLTeR[m]: It will only work if the protocol involves the client communicating the app developer's email address to send the nag to
12:26kchibisov: it'll stop working once someone add new shm format.
12:26davidre: pq: Would rely on the client implementing the extension correctly, has to be part of the wire protocol like an error
12:26pq: YaLTeR[m], that's miles better than "I sometimes see a pink flash, help"
12:26davidre: New message type "nag"
12:28Company: the most evil thing to punish an app is to make it lag
12:28Company: just don't render a new buffer for half a second
12:28YaLTeR[m]: Also I mean, the clients are free to submit whatever size they want to a normal configure. Qt doesn't even bother to communicate min size for example
12:28kchibisov: you don't need min size if you can render at any size.
12:28YaLTeR[m]: Company: that strategy is currently being tested by Nvidia proprietary drivers
12:29pq: yet another tiny protocol extension coming to my mind is, when a compositor smashes a client with an actual protocol error, it could first send a log of the most recent protocol messages leading to the error, likewise for the client to put into its logs
12:29d_ed[m]: > Qt doesn't even bother to communicate min size for example
12:29d_ed[m]: that's not true
12:29d_ed[m]: oh
12:29YaLTeR[m]: Dunno, flatpak telegram and obs don't set min size here
12:29YaLTeR[m]: they sure have one just don't tell the compositor about it
12:31pq: that way there is no need to repeat the error with `WAYLAND_DEBUG=server`, and people use `WAYLAND_DEBUG=client` instead because its easier but also does not pinpoint the failing reqeust.
12:31pq: even just 2 kB of plain text protocol dump might help, I imagine
12:33vyivel: this could be implemented as a proxy probably
12:33emersion: yeah, akin to Vulkan validation layers
12:34pq: a) get server's view of the protocol messages, b) save that with client's own logs, c) always enabled in production
12:34pq: like any flight-recorder type of thing should
12:35pq: so there is no need to attempt to reproduce to get this bit
12:36d_ed[m]: <YaLTeR[m]> "Dunno, flatpak telegram and..." <- I checked flatpak telegram here, debug log showed it being set fine
12:36pq: one could probably shove that in wl_display.error event, too
12:36emersion: i'm not convinced, pq
12:37vyivel: hm, i can probably do that on compositor side with wl_display_add_protocol_logger
12:37pq: vyivel, exactly.
12:37emersion: i have a hard time thinking that clients will do anything useful with the info
12:38pq: emersion, even getting it out to their stderr would probably help.
12:38YaLTeR[m]: d_ed[m]: weird, I'll need to double check
12:39emersion: so, what should we do about that set_maximum_size + maximized state issue
12:40emersion: forbid compositors from sending a configure size inconsistent with the client constraints?
12:40emersion: allow clients to disallow the configure size if it's outside of their constraints?
12:40emersion: err
12:40emersion: allow clients to disobey the configure size if it's outside of their constraints?
12:40emersion: what about race conditions when setting the constraints?
12:41davidre: Well
12:41pq: what should happen when there is no size at all that would make both compositor and client happy?
12:41davidre: currently it says
12:41davidre: > The client should not rely on the compositor to obey the maximum size.
12:42davidre: But we have cases already where we have app developers not happy that their Qt apps are sized smaller than minimum size on wayland
12:42ifreund: would they rather the compositor inform them that the program will be sized smaller or just lie to the client and crop the buffer?
12:43ifreund: cause as a compositor author, I will do what the compositor user wants not what the app wants
12:43d_ed[m]: the user wants their apps to work!
12:43d_ed[m]: they're the same thing
12:44ifreund: the user may want the app in question to be in a tiling layout where it is visible but not at a usable size until given focus for example
12:44kennylevinsen: in the prefect world, all constraints are compatible
12:44ifreund: or what if for example, the minimum size is larger than the size of the output?
12:44ifreund: (in any dimension)
12:45kennylevinsen: e.g., the issue with minimum size would often be in tiling, where there isn't more space to give, so rendering larger means spilling over other things which makes no one happy...
12:46pq: Scroll bars. No, seriously. If compositor has to make a window smaller than the app can arrange its GUI, then the only way it can work is some kind of scrolling thing. Maybe automatically by pointer position. Or scaled down, if legibility is less important.
12:46kennylevinsen: (I often try to stack telegram, signal and IRC vertically on the side of my monitor for example, and telegram annoyingly refuses to render that small when on 1920x1200, spilling over the top of my signal window :( )
12:46d_ed[m]: What we should do is document that apps should fit the space asked by the compositor whatever it is. Then write robust compositors that can handle that being not the case, in a non-perfect middle ground. Whether that's unmaximising/ cropping / scaling/letterboxing / rendering warnings.
12:47kennylevinsen: (but in that case the issue is of course that telegram has a somewhat arbitrary minimum size, which could easily have been smaller - I wouldn't have tried if the UI wouldn't fit)
12:48davidre: We changed Qt so it will now obey and become smaller
12:49davidre: It sometimes not sending min_size is a bug that's fixed in the next patch release
12:49davidre: * It sometimes not sending min_size as well is a bug that's fixed in the next patch release
12:50ifreund: that's nice to hear :)
12:50kennylevinsen: pq: clipping and scrollbars would be a bit wonky with csds, but in the case where UI elements truly cannot be shown that small, having the compositor try to help seems somewhat reasonable. The user both wants a useable app *and* for it to fit in a certain space after all
12:50kennylevinsen: davidre: :D
12:52pq: too bad I couldn't find a video of Weston's output zoom, now deleted feature I think. That was one possibility for mouse users in how to fit a big thing in a small viewport
12:54pq: but all this sounds like clients would not need to honour max size limits if they cannot?
12:54pq: limits imposed by a compositor
12:56pq: a compositor can always scale or crop+scroll client content that is too big for the space
12:56pq: UX without a mouse though...
13:59YaLTeR[m]: d_ed: flatpak telegram does indeed send min size now, flatpak obs still not. Guess it's a recent fix
14:54wlb: weston Merge request !1466 opened by Loïc Molinari (molinari) Fix release/debugoptimized build warnings with gcc https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1466
15:12wlb: weston/main: Leandro Ribeiro * 14 commits https://gitlab.freedesktop.org/wayland/weston/compare/ffe08c43449bed585975259625e3de2bb4a57b9e...7e22c28444f59fce93b76a287fcfaacd57229419
15:12wlb: weston Merge request !1455 merged \o/ (Color manager cleanups https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1455)
15:47kennylevinsen: random friday thought: I feel like there should be a YUV121010 format to get more out of a 32-bit pixel than XRGB2101010
15:47pq: good point
15:48kennylevinsen: or YUV160808, might fit better as a multi-plane format. Not sure which balance is right.
15:49pq: wonder if 1688 would be enough chroma too
15:49kennylevinsen: I mean, with my very limited understanding of how borked our vision is, I imagine we'd get more out of "moar luma"
15:50pq: certainly
15:51pq: one could do a test: render some gradients in BT.2020 YUV160808, convert to RGB32F, clip to BT.709, and see if the surviving parts of gradients exhibit any banding.
15:56kennylevinsen: I'd have to look up some color math then :)
15:58kennylevinsen: hmm, clipping to bt.709 would clip saturation right? so we're reducing the chroma resolution further. What would that test actually tell us? :/
16:02kennylevinsen: other than "chroma is so abundant it doesn't band even after throwing bits away"
16:12pq: exactly
16:13pq: BT.2020 is probably the widest color gamut for practical uses, so if there is enough chroma precision to cover that all, then it's probably good enough.
16:14pq: unfortunately we cannot display full BT.2020, so we have to display a part that is actually doable, like BT.709
16:15pq: if that part looks like, then we could guess that maybe the other parts are good enough as well
16:15pq: *looks fine
16:17pq: or you could some serious scientific modeling, but I thought this would be a more fun experiment :-)
16:27MrCooper: emersion: how can I tell gamescope which DRM device to use in a VT?
17:38emersion: MrCooper: it's synced with the Vulkan device
17:38emersion: iirc
17:39MrCooper: that doesn't seem to work, the KMS atomic cap test fails (as it would for the other GPU)
17:40emersion: it should work
17:40emersion: https://github.com/ValveSoftware/gamescope/blob/d0d23c4c3010c81add1bd90cbe478ce4a386e28d/src/drm.cpp#L1081
17:45MrCooper: it prints "drm: warning: picking an arbitrary DRM device", then "drm: drmSetClientCap(ATOMIC) failed"
17:47emersion: eh, that means it's not doing the right thing
17:47emersion: maybe vulkan init comes too late or something due to a recent change
17:48MrCooper: maybe Debian's 3.12.5-1 is just too old?
17:50emersion: it could be that mesa is too old to expose the Vulkan DRM device ext?
17:50emersion: tbh we should error out instead of picking an arbitrary device there
17:50emersion: or maybe check that there is just a single device