06:00 wlb: weston Merge request !1424 opened by Chao Guo (ChaoGuo) compositor: improve viewport source validity check https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1424
09:12 YaLTeR[m]: I've got a question about popup constraints. Flip constraints say: "If the adjusted position also ends up being constrained, the resulting position of the flip_x adjustment will be the one before the adjustment." What does this mean? Other constraints don't say this. What happens if flip is combined with other adjustments?
09:33 vyivel: YaLTeR[m]: iirc you first try to flip, if the popup is still constrained, you undo the flip and try other options
09:34 YaLTeR[m]: Hmm
09:34 YaLTeR[m]: So no combining flip and others then
09:36 YaLTeR[m]: How do X and Y adjustments interact? In the case when both axes adjustments are needed to remove constraints?
09:40 vyivel: you apply both then?
09:42 YaLTeR[m]: Say I try to flip X, then I need to try the whole range of Y adjustments to see if it's possible to remove constraints? Or I try to flip X and then only try to flip Y before proceeding to other X adjustments?
09:44 vyivel: if flipping x succeeds in removing constraints, you don't need to do anything else with the x axis
09:44 vyivel: if it doesn't, you don't flip
09:44 vyivel: x and y are independent from each other
09:44 vyivel: that's how i see it at least
09:45 YaLTeR[m]: If the popup is in a corner, it may need two adjustments at once to remove the constraint, and any single-axis adjustment will keep it constrained
09:45 vyivel: i mean, flip x and check if x constraints are removed
09:45 vyivel: if they are, keep the x flip
09:45 vyivel: same with y
09:48 YaLTeR[m]: This is getting edge casy, but if the popup is wider but not taller than the screen, then it cannot be unconstrained, and you won't know that if you only look at the Y axis
09:49 YaLTeR[m]: so when applying flip y you will succeed, but actually the popup is still constrained, so you should've reverted it
09:50 vyivel: hm right
09:50 vyivel: fwiw wlroots unconstrains axes independently
09:50 vyivel: btw if you're working on implementing that here's a funny thing https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/84
09:52 YaLTeR[m]: I was about to ask about slides, because as far as I can tell, all this wording about which sliding direction to try first does not actually result in any behavior difference, if applied as currently worded
09:53 YaLTeR[m]: regardless of whether you try to slide left or right first, you will hit the same edge eventually and end up with the same position
09:53 YaLTeR[m]: unless I'm misunderstanding
12:04 kennylevinsen: If the popup cannot be unconstrained with sliding, I think the order sliding is attempted will affect the final position (whether you align the edge closest to or furthest from gravity)
12:06 kennylevinsen: the undo is only for flip IIRC, because it isn't productive to stack, but sliding + resize means you align the surface before crop
12:07 kennylevinsen: and yeah, I think you should treat each axis independently - even if you can't solve a Y constraint, it's still better UX to solve the X constraint rather than bail
12:43 YaLTeR[m]: Right
13:18 wlb: weston/main: Pekka Paalanen * libweston: drop weston_output_init() test workaround https://gitlab.freedesktop.org/wayland/weston/commit/b84ad9e34c50 libweston/compositor.c
13:18 wlb: weston Merge request !1421 merged \o/ (libweston: drop weston_output_init() test workaround https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1421)
13:22 pq: Oh boy, my old HDR monitor definitely does *something* with "Colorspace" KMS property. Switching it from default to bt2020rgb makes thing... psychedelic - but of course, I'm feeding it plain old sRGB data, so of course it'll be wrong, but this is wild.
13:22 pq: black becomes mid green, gray becomes pink...
13:23 ManMower: that's just using RGB values as YUV?
13:24 pq: no, RGB as RGB
13:24 pq: just telling the monitor that my color gamut is waaay beyond what it can display
13:25 kennylevinsen: When "vivid" is turned all the way up to 11
13:25 ManMower: ah ok, was expecting like https://answers.opencv.org/upfiles/15941108489577923.jpg
13:25 Ermine: Nice pic!
13:27 pq: What's even funnier is that I cannot even take a photo of the screen with my phone. What I see as saturated green in reality, is cyan in the photo.
13:31 ManMower: never had this problem with film!
13:31 ManMower:shakes fist at clouds
13:33 zamundaaa[m]: pq: yeah taking photos of HDR content is hard. I managed to take a decent one of an HDR video with nature content, but games always look like shit
13:42 pq: uh oh
13:43 pq: something in the display system broke
13:44 pq: timestamps from amdgpu are out of whack
13:45 emersion: anything in dmesg?
13:46 pq: nope, aside from a couple dozen kernel: HDR SB:3d 02 00 d0 84 80 3e c2 33 c4 86 4c 1d b8 0b 13 kind of lines
13:47 pq: monitor complains of no signal, and Weston gets abnormal repaint delays 150k secs in the past.
13:48 pq: hmm, turning the monitor off and on fixed it, which means hotplug
13:49 pq: I think Weston was going to sleep mode, turning the output off, when it broke.
13:50 pq: Anyway, at least I can confirm one thing I got wrong: setting "Colorspace" really matters, even if you already set "HDR_OUTPUT_METADATA".
13:57 pq: looks like the absence of HDR static metadata HDCP infoframe does *not* reset this monitor to SDR. But setting colorimetry to "default RGB" does.
13:58 pq: also, fbdev does not reset colorimetry when taking over :-P
14:05 zamundaaa[m]: <pq> "looks like the absence of HDR..." <- It's not that specific monitor, it happens with all of them
14:06 pq: hmm, I thought I read in spec somewhere that it should reset.
14:07 pq: but I also have a vague recollection that one should also send HDR static metadata just to ensure HDR is off when the sink supports it...
14:07 zamundaaa[m]: pq: I think it's an amdgpu bug actually, not necessarily the displays behaving badly
14:08 zamundaaa[m]: It does reset after a modeset
14:08 pq: or, it's an amdgpu bug - I'm just using drm_info to see what I'm supposedly sending to the monitor.
14:09 pq: hmm, so getting HDR_OUTPUT_METADATA property to none does not propagate on amdgpu without a modeset?
14:09 pq: any bug filed about that?
14:09 pq: or maybe even already fixed and we're just behind in kernels?
14:09 pq: hwentlan__, ^
14:11 pq: there is a modeset, surely, though? When fbdev returns, and definitely once Weston starts again.
14:11 zamundaaa[m]: pq: maybe it's not a modeset that triggers the change, but switching between drm masters or something
14:12 pq: fbdev is a different master...
14:12 zamundaaa[m]: For me if I log out of the session with HDR enabled, SDDM shows SDR interpreted as HDR, and if I log into a session with SDR, then it's correct again
14:12 pq: what fixed it for me was starting Weston with "Colorspace" set to default
14:14 pq: I would guess that SDDM does not touch "Colorspace" nor "HDR_OUTPUT_METADATA", and fbdev does not either. But your HDR-capable compositor might ensure they are correct for SDR sRGB, too. I certainly hope it does.
14:14 zamundaaa[m]: yeah that also does it for me. That's part of the reason for why the GUI only exposes both properties as one "HDR" toggle
14:15 zamundaaa[m]: pq: I *think* I made KWin 5.27 reset the properties actually. Let me check
14:16 pq: well... I get a very reasonable image with PQ and default RGB, and also WCG monitors without HDR exist.
14:17 zamundaaa[m]: ah, KWin 5.27 only resets HDR_OUTPUT_METADATA. It doesn't touch Colorspace
14:18 zamundaaa[m]: So it's not too surprising it still looks weird in SDDM
14:18 pq: Weston sets HDR_OUTPUT_METADATA to 0 instead of the SDR blob.
14:18 pq: What's most exciting about my experiments is that I think an end user tool to figure out the color gamut of a HDR monitor without any measurement equipment seems very possible.
14:25 pq: This is the photo: https://fosstodon.org/@pq/111601663856163009
14:47 pq: now I'm slightly worried, because I had to start Weston twice, before the monitor went into the proper WCG HDR mode.
15:40 wlb: weston Issue #633 closed \o/ (Rename compositor/ directory https://gitlab.freedesktop.org/wayland/weston/-/issues/633)
15:40 wlb: weston/main: Pekka Paalanen * tests: remove unnecessary weston.h includes https://gitlab.freedesktop.org/wayland/weston/commit/c36bbad8e26c tests/ ivi-layout-internal-test.c plugin-registry-test.c surface-global-test.c surface-test.c
15:40 wlb: weston/main: Pekka Paalanen * Rename compositor/ to frontend/ https://gitlab.freedesktop.org/wayland/weston/commit/336f7fabec43 frontend/cms-colord.c frontend/cms-helper.c frontend/cms-helper.h frontend/cms-static.c frontend/config-helpers.c frontend/executable.c frontend/main.c frontend/meson.build frontend/screen-share.c frontend/systemd-notify.c frontend/text-backend.c frontend/
15:40 wlb: weston Merge request !1422 merged \o/ (Rename compositor/ to frontend/ https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1422)
15:41 pq: Woo! And with that, I'm off.
15:42 daniels: o/
15:45 bl4ckb0ne: o/
17:40 wlb: wayland-protocols Issue #171 opened by Jrelvas (Jrelvas) Brainstorming: Optimizing for hardware planes https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/171
18:56 wlb: weston Merge request !1425 opened by Ray Smith (rsmith) backend-drm: fix confused fallback format handling https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1425
19:21 wlb: weston Merge request !1426 opened by Ray Smith (rsmith) backend-drm: always create gem_handle_refcnt hash table https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1426
19:46 wlb: weston Merge request !1427 opened by Ray Smith (rsmith) backend-headless: Don't try to finish frame if it was cancelled https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1427
21:33 wlb: weston/main: Khem Raj * libweston,tools: Include libgen.h for basename signature https://gitlab.freedesktop.org/wayland/weston/commit/dbd134ca5a3c libweston/backend-drm/libbacklight.c tools/zunitc/src/zunitc_impl.c
21:33 wlb: weston Merge request !1420 merged \o/ (libweston,tools: Include libgen.h for basename signature https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1420)
21:44 wlb: weston/main: Michael Olbrich * ivi-shell: clear seat focus if necessary when a surface is destroyed https://gitlab.freedesktop.org/wayland/weston/commit/d6681cedeec3 ivi-shell/ivi-shell.c
21:44 wlb: weston Merge request !1417 merged \o/ (ivi-shell: clear seat focus if necessary when a surface is destroyed https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1417)