07:46wlb: weston Issue #747 opened by Link Mauve (linkmauve) Segfault while playing a Xwayland game https://gitlab.freedesktop.org/wayland/weston/-/issues/747
08:57wlb: weston Issue #748 opened by Link Mauve (linkmauve) Segfault while writing in Firefox https://gitlab.freedesktop.org/wayland/weston/-/issues/748
09:29wlb: wayland-protocols Merge request !206 opened by Simon Ser (emersion) ci: use detached CI pipelines https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/206
09:30wlb: wayland-protocols/main: i509VCB * Add ext-foreign-toplevel-list protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/77b4681f1640 staging/ext-foreign-toplevel-list/README staging/ext-foreign-toplevel-list/ext-foreign-toplevel-list-v1.xml meson.build
09:31wlb: wayland-protocols Merge request !187 merged \o/ (Add ext-foreign-toplevel-list protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/187)
09:34emersion: i messed up the merge ><
09:34emersion: oh well
09:37zzag: Missing Signed-off-by?
09:40wlb: wayland-protocols/main: Simon Ser * ci: use detached CI pipelines https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/fbf7fc351715 .gitlab-ci.yml
09:40wlb: wayland-protocols Merge request !206 merged \o/ (ci: use detached CI pipelines https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/206)
11:23emersion: zzag: yeah, because GitLab squashed everything
11:24ifreund: Time to disable squash merging then?
11:24emersion: but then it would just push the 27 individual commits which isn't a lot better
11:24emersion: but yeah
11:25emersion: I need to be more careful, really missed that when clicking
11:25ifreund: Well, the the merger would have to manually squash and force push the branch
11:25ifreund: so that CI runs on the (squashed) commit to be merged before the button can be pressed
11:26ifreund: gitlab allowing you to merge a commit without CI passing on it seems like a gitlab/configuration issue, not your fault emersion
11:29zzag: ifreund: if you click "squash commits", there's another checkbox to allow editing the commit message
11:29jadahl: ifreund: the merger shouldn't squash, the contributor should
11:31ifreund: zzag: it seems to me that however the commit message turns out CI is not run on the resulting commit before merging to master
11:31ifreund: if it was, emersion wouldn't have been able to merge that commit
11:32zzag: jadahl: agreed. kde-wise we permit such workflows, but I hate it because it's unclear what the author wants to get in master branch
11:32zzag: also if the MR contains 30, 40, 50 or more commits, it's barely reviewable
11:34ifreund: jadahl: sure, that would be ideal. For my projects I sometimes squash things myself while merging rather than bug the contributor/teach them how. Mostly just for drive-by contributions though
11:34jadahl: yea, it's also much harder to backport things if it goes back and forth changing things here and there before finally ending with the final result
11:36emersion: alright, let's disable squash then
11:36emersion: done
11:38elibrokeit: ifreund: CI does not need to run on the resulting commit, why would you remotely care about that?
11:39ifreund: elibrokeit: in this case the CI lints the commit message to ensure it has a Signed-of-by: trailer
11:39ifreund: s/of/off/
11:41elibrokeit: It's logically wrong for this to be done by CI, but software forges rarely allow you to set up pre-receive githooks
11:42ifreund: I can agree with that :)
11:42wlb: wayland-protocols Merge request !207 opened by Simon Ser (emersion) ci: skip ci-fairy checks on main branch https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/207
11:43elibrokeit: as far as CI goes, you only really care that the same tree object is tested, this logical rule covers squash and rebase merges as a side effect -- and has no effect on fast-forward merges -- by asserting the desire that merged MRs should only be merged when the resulting software state is tested regardless of how you edit commit messages during the merge itself
11:43elibrokeit: unfortunately this is not necessarily possible either
11:44elibrokeit: which is why e.g. marge-bots exist
11:45mvlad: short psa, tomorrow is the alpha release for weston 12.
11:58wlb: wayland-protocols/main: Simon Ser * ci: skip ci-fairy checks on main branch https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/cc0cd4addf68 .gitlab-ci.yml
11:58wlb: wayland-protocols Merge request !207 merged \o/ (ci: skip ci-fairy checks on main branch https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/207)
18:23_DOOM_: How would a compositor in practice make backwards compatible code for protocols?
19:09kennylevinsen: _DOOM_: it would check the protocol version of the bound global object. Usually all it needs to do is filter newer events, but it could switch implementation if things are vastly different.
19:10_DOOM_: Would using the resource version be a good method for checking protocol version?
19:18kennylevinsen: _DOOM_: example: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/types/wlr_compositor.c#L1096
19:22_DOOM_: Okay
19:22_DOOM_: That is what I thought. Thanks!
21:16JoshuaAshton: pq: Didn't see your ping... I need to get my IRC client to stop replaying people disconnecting/reconnecting >.>
21:17JoshuaAshton: scRGB has 709 primaries, but can express any perceptible or non-perceptible color due to it having negative values
21:18JoshuaAshton: When considering games, you should consider that typically games and game developers don't know what a primary is :p
21:18JoshuaAshton: They were authored for whatever they were displayed on
21:19JoshuaAshton: Game developers using scRGB are probably taking their existing pipeline that outputs to sRGB and just changing their tonemapping step and buffer format
21:19JoshuaAshton: That's not to say that no-one is using negative stuff in scRGB though
21:20JoshuaAshton: but it is to say that, when you are outputing to 2020 HDR10 PQ anyway (nobody actually supports scRGB on the display side despite there being a DP entry for it), the best way is to just do 709 -> 2020 with a CTM then encode as PQ
21:21JoshuaAshton: Like, if you are wanting to scanout a scRGB buffer, it's going to have to go to PQ
21:22JoshuaAshton: You could do PQ with 709 primaries I guess -- but it's a gamble whether monitors actually respect the colorspace packet in HDR mode, there's quite a few that just go straight to 2020, and also some that stay in 709 and only go to 2020 when you send the colorimetry packet
21:22JoshuaAshton: That also wouldn't handle negatives
21:22JoshuaAshton: So ime, PQ + 2020 is really your only options if you want to handle broken displays.