01:29wlb: wayland Issue #384 opened by Sky (flyinskyin2013) wayland backend: wl_display@1.error(wl_display@1, 1, "invalid arguments for xdg_toplevel@17.resize") in GTK3.0 https://gitlab.freedesktop.org/wayland/wayland/-/issues/384
06:26DodoGTA: DemiMarie: For toggling some settings (like FSR or HDR) for a specific surface on the fly for example
06:27DodoGTA: Here are all the atoms that gamescope uses for reference: https://github.com/ValveSoftware/gamescope/blob/master/src/xwayland_ctx.hpp#L76-L208
06:44kennylevinsen: those atoms are in effect a gamescope-specific protocol that steam games would speak
06:45kennylevinsen: So in Wayland, they would be a gamescope-local protocol (or side-channel)
06:48kennylevinsen: one does also not simply *toggle HDR*, but would presumably use a different protocol to configure color space, mastering brightness and all the other keywords that the people working on color and HDR use.
06:49kennylevinsen: So no - no atoms, and no plans to be a generic key-value store.
08:13pq: DodoGTA, exactly what kennylevinsen said. For a key-value store to be useful, you need both the client and the compositor understanding the same things the same way. That is a definition of a protocol. In Wayland we do that with Wayland extensions, they can also be private if they have no use outside a specific compositor+client combo.
08:15pq: DodoGTA, if you actually used a key-value store, then how do you know if the other side understands what you set? You could add even more keys with values to define that, sure. It's just not Wayland style, we have already design patterns for feature discoverability.
11:21pq: swick[m], did you join that call yesterday? Did you see the presentation by Cameron on HDR broadcast vs. desktop, anything new there?
12:12swick[m]: unfortunately no
12:12swick[m]: something came up
12:13pq: ok
12:13swick[m]: thanks for asking the questions that I want to ask as well on the w3c thing
12:13pq: heh
14:07wlb: weston Merge request !1256 opened by Kai Liu (lk1025) xwm: WM_TRANSIENT_FOR should not point to override-redirect window https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1256
16:23JoshuaAshton: DodoGTA: kennylevinsen: FWIW, the "client" here is Steam. Only it and Gamescope use these atoms.
16:23JoshuaAshton: Not the games themselves
16:23JoshuaAshton: The games do use a gamescope-specific Wayland protocol for buffer tagging (and other swapchain feedback)
16:27kennylevinsen: makes sense, but also makes sense that magic gamescope <-> steam chat is a gamescope protocol
16:27JoshuaAshton: Yeah
16:27JoshuaAshton: Right now all the HDR stuff is implemented via a Vulkan layer
16:28JoshuaAshton: Right now Colorspace etc on a VkSwapchain do nothing, but this just forwards that info (+ SetHdrMetadata) along to gamescope
19:04bwidawsk: Are there other examples like org_kde_kwin_slide that describe animation of things?
19:05emersion: i'd like one for opacity
19:05emersion: there is a MR for blur
19:05bwidawsk: emersion: do you have the link handy?
19:06bwidawsk: yeah
19:06bwidawsk: oops, wrong window
19:06emersion: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/43
19:06bwidawsk: emersion: thank you
19:07bwidawsk: ah, another kde one
19:07bwidawsk: missed it
19:08emersion: i think it could land with minimal effort…
19:47nielsdg: pq, swick: jfyi https://phabricator.kde.org/T16449
19:48emersion: "They both plan to do the same thing"
19:48emersion: oh that's encouraging
19:48emersion: as in, we're not the only ones thinking it's the way to go
19:54swick[m]: that... doesn't sound very similar
19:55swick[m]: nielsdg: let's figure out if we can take part in the discussion on monday then
19:55swick[m]: lots of interesting links about Windows stuff I was not aware of
19:58nielsdg: Yeah, the links were interesting indeed
19:58nielsdg: I asked in #krita if they would mind having us