08:16 any1: outfoxxed[m]: A new buffer can be considered fully damaged, yes.
08:17 wlb: weston/main: Paul Pu * desktop-shell: support disallow-output-changed-move https://gitlab.freedesktop.org/wayland/weston/commit/ddb6225338da desktop-shell/shell.c desktop-shell/shell.h man/weston.ini.man
08:17 wlb: weston Merge request !1671 merged \o/ (desktop-shell: support disallow-output-changed-move https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1671)
08:20 any1: Those long matrix links get wrapped in my IRC client and other "UI elements" interfere with selection.
08:32 outfoxxed[m]: <any1> "outfoxxed: A new buffer can be..." <- is the compositor supposed to track that its a new buffer or am I though
08:33 outfoxxed[m]: I'm assuming the client should
08:57 pq: outfoxxed[m], a Wayland client should never assume that a compositor adds full wl_surface damage when it attaches and commits a wl_buffer that leads to a different wl_surface size.
08:58 outfoxxed[m]: This isn't wl_surface damage, this is ext_image_copy_capture_frame damage, but I assume its the same
08:58 pq: Making sure that wl_surface damage is sufficient is the client's responsibility.
08:59 pq: ah, then I have no idea, sorry
10:14 wlb: wayland-protocols Issue #237 closed \o/ (Proposal: Gamma control Protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/237)
10:52 any1: The server has no way of tracking this. It's up to the client.
13:39 wlb: weston/main: Daniel Stone * 28 commits https://gitlab.freedesktop.org/wayland/weston/compare/ddb6225338da197152d1f87d1b995812e5c42bb5...a2dba7ff0001bae4ea67bd470ca631222df2780b
13:39 wlb: weston Merge request !1628 merged \o/ (Extension and feature flags https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1628)
14:07 emersion: zamundaaa[m], pq: thanks a lot for the comments on the libdi MR!
14:07 emersion: zamundaaa[m]: do you have a ref wrt. what KDE is doing?
14:08 pq: np :-)
14:09 emersion: zamundaaa[m]: also, do you think we should bake in any other field?
14:11 zamundaaa[m]: emersion: do you mean what we use as the equivalent, or the whole config system?
14:11 emersion: how do you match outputs in the config?
14:13 zamundaaa[m]: Very carefully :D I'm currently in a meeting, I'll type up an explanation in a bit
14:17 emersion: no rush, ty :)
15:24 zamundaaa[m]: emersion: I *think* I got everything in here. Note that what I explain is a not-yet-merged rewrite of the output identification algorithm, as the previous code didn't handle some edge cases perfectly.... (full message at <https://matrix.org/oftc/media/v1/media/download/AVOv3E0oIZSBGI2m2HdZMtGhzR-9a23fDVDmA5Ql-wrjgGGTTpfYFcSrV8tQvTSgf0oMijCNSqwGItlasHHwYNlCeUrYMscgAG1hdHJpeC5vcmcvRER6Tm5xRHZrSGhFRmxFd1FNVFZ4SFlJ>)
15:26 emersion: i see, so it keeps trying to narrow down based on metadata as long as more than 1 stored config matches
15:26 emersion: note, the full MST path isn't stable, you need to remove the parent connector ID
15:26 zamundaaa[m]: We do remove it
15:26 emersion: cool
15:27 emersion: also see: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3979
15:27 emersion: for a full identifier for connector ports
15:27 emersion: with connector index and DRM device path
15:31 emersion: and yeah, connector name is not stable
15:32 emersion: zamundaaa[m]: "The EDID ID in KWin is like the proposed device tag."
15:32 emersion: how is it constructed?
15:37 zamundaaa[m]: https://invent.kde.org/plasma/kwin/-/blob/master/src/utils/edid.cpp?ref_type=heads#L157
15:39 emersion: okay, so same except it doesn't use the strings, only the integer codes
15:40 zamundaaa[m]: Yeah. I'd like to add the device tag to the list to fix that :)