00:03 wlb: wayland-protocols Issue #205 opened by Demi Marie Obenour (DemiMarie) `dev_t` doesn’t work in VMs https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/205
02:28 wlb: wayland-protocols Issue #206 opened by Dennis Lonoshchuk (laycookie) Allow null to be passed as output method in zwlr_screencopy_manager_v1::capture_output and zwlr_screencopy_manager_v1::capture_output_region https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/206
06:54 wlb: wayland-protocols Issue #206 closed \o/ (Allow null to be passed as output method in zwlr_screencopy_manager_v1::capture_output and zwlr_screencopy_manager_v1::capture_output_region https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/206)
13:41 wlb: weston Issue #935 closed \o/ (weston fails to start drm session https://gitlab.freedesktop.org/wayland/weston/-/issues/935)
13:53 Company: swick[m]: Is there a reason why the named primaries and transfer functions don't map to cicp values?
13:54 Company:bets there is one in the long MR somewhere
13:56 Company: because I'm wondering if GTK should define its own enum and have a mapping somehow or just use cicp and punt everything to icc profiles or wherever else
14:01 swick[m]: Company: they do for the most parts?
14:01 swick[m]: like, not numerically
14:01 Company: yeah, I meant numerically
14:02 Company: almost every library has a to/from_cicp() function and a custom enum
14:02 Company: but that seems to be mostly because they're older than cicp
14:02 Company: but this protocol is newer
14:02 Company: so could choose to match numerically
14:03 Company: that would avoid everyone having to write another to/from set of functions
14:04 Company: but it'd also mean you'd be bound to cicp wrt extending it
14:06 swick[m]: yes, we had the CICP code points originally: https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/56
14:16 Company: the conclusion seems to be "ugh, cicp is so broken, let's not do that"
14:18 Company: which I can totally sympathize with
14:19 Company: but then, everyone knows how to use it, so for GTK it'd probably be really useful
14:19 Company: though everyne would deal with another mapping, too
17:15 wlb: weston Merge request !1577 opened by Leandro Ribeiro (leandrohrb) backend-drm: get EOTF mask and colorimetry mask from EDID https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1577 [DRM/KMS backend]
18:30 colinmarc: When I emit wl_output mode changes, games running via xwayland don't seem to pick up the new mode in their video/graphics settings, although reconfiguring the xwindow usually works. Am I missing something in terms of plumbing that together or is that supposed to just work?
18:41 zamundaaa[m]: Colin Marc: I'm afraid most games are just that dumb
18:42 colinmarc: hehe :(
18:42 zamundaaa[m]: You could maybe check if the games you test react to mode changes on normal Xorg, or on Windows, but I doubt it
18:51 roboporo: anyone know what can cause the green artifacts like in the image when doing direct scanout? https://imgur.com/a/g6ZZd7w
18:57 colinmarc: the other thing I've been confused by is that when I do a mode change - let's say from 1920x1080 -> 1600x1200 - and then reconfigure the xwindow, the buffer size changes to 1600x1200 even if the application seems not to resize, and the pointer motion events are interpreted as if the window is still the old size
18:57 colinmarc: is xwayland scaling the xwindow output down to the correct size even if the xwindow itself isn't respecting the configuration?
18:58 colinmarc: (this is with borderless fullscreen)
19:03 colinmarc: ah, hm, that's not every game. maybe just this one (talos principle 2)
20:06 JoshuaAshton: Don't think any games react to mode changes on Windows
20:06 JoshuaAshton: Usually they just crash or don't update anything or end up crashing if you try to change modes after if one isn't valid anymore
20:07 JoshuaAshton: On SteamOS, the game gets it's own XWayland and the mode is fixed for the lifetime of the game being present
20:10 colinmarc: JoshuaAshton: thanks. I went looking for where that is implemented in gamescope but it just seems like it's using wlroots's xwayland process, which would be one rootless, no? or are there just multiple gamescopes?
20:11 colinmarc: if gamescope is running nested windowed and someone resizes it, it doesn't change the mode in that case?
20:11 colinmarc: this stuff is so hairy...
20:49 JoshuaAshton: XWayland updates its mode on wl_output change
20:49 JoshuaAshton: We don't update the mode when Gamescope window is resized
20:50 JoshuaAshton: Actually I lie, we would update XWayland 0 which woudl be Steams so Steam would update its size
20:50 JoshuaAshton: but the game would not
21:32 colinmarc: hm, I've found at least some games with "responsive" menu screens that aren't behaving properly on my compositor. so I think I just have a bug somewhere, I think in the xwm. the weird thing is, the buffer is getting sized correctly, so something upstream is scaling, I think xwayland.
21:33 FreeFull: colinmarc: Maybe it's using viewporter?
21:33 colinmarc: I haven't implemented viewporter (could that be the problem?)
21:34 FreeFull: Maybe if xwayland does the wrong thing if viewporter isn't present.. Pure speculation, though
21:58 colinmarc: ok, what fixed it was setting _NET_WM_STATE_FULLSCREEN even if the game is in borderless fullscreen. I don't understand enough about x11 semantics to know whether that's correct or a cludge, but it works.
22:01 colinmarc: I guess that kicks xwayland out of compositing mode?
23:33 JoshuaAshton: xwayland or xserver doesn't check icccm properties
23:33 JoshuaAshton: what is a responsive menu screen?
23:35 karenthedorf: "responsive" means it adjusts to window size/dpi. Or that''s what it means in webdev