02:32 wlb: weston Merge request !1671 opened by Paul Pu (puhui) Draft: desktop-shell: support disallow-output-changed-move https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1671
03:27 wlb: weston Issue #988 opened by w09402006 (w09402006) weston multi-screen display https://gitlab.freedesktop.org/wayland/weston/-/issues/988
09:16 wlb: weston Issue #988 closed \o/ (weston multi-screen display https://gitlab.freedesktop.org/wayland/weston/-/issues/988)
10:28 Consolatis: gentle ping for someone with merge rights in w-p: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/367 seems to have fulfilled all the requirements to be merged
10:34 outfoxxed[m]: When using ext_image_copy_capture_session_v1, if the compositor re-emits any constraints, how are existing constraints supposed to be handled?
10:35 outfoxxed[m]: lets say the compositor sends... (full message at <https://matrix.org/oftc/media/v1/media/download/AXopzll7JXH7CT8pvZpbJXPqoqjRMwpDdFfxifmh5BeiuZPqp7eEtgk-Qu7r0zJAS8YaxsMzvm8ETnug7W-Bs_JCeUp1RNxQAG1hdHJpeC5vcmcvYWRSaEdrYXJiblZJR2tqSGpSZXpDbWJB>)
10:35 outfoxxed[m]: and what if some other property changes?... (full message at <https://matrix.org/oftc/media/v1/media/download/AamO_nNs583WK9ONT43EBlYWx7ONsP0dbQD21jCVKoNrMRGmcp-q8FueEuMnMXSlEmCotzSEWc1zPmBvJxGJt5NCeUp1T1NwAG1hdHJpeC5vcmcvelhiQVJCRkVPWVhqSkdocUFwSFdleFZV>)
10:36 outfoxxed[m]: is this no shm formats or {0}
10:36 emersion: your messages don't get through properly
10:36 emersion: all the constraints are re-sent iirc
10:36 outfoxxed[m]: is this a matrix-irc bridge issue?
10:37 emersion: they get linkified
10:37 outfoxxed[m]: thats unfortunate
10:37 outfoxxed[m]: emersion: so when receiving any of {buffer_size, shm_format, dmabuf_device, dmabuf_format} after receiving done, clear the old values of all of them?
10:40 emersion: yea
10:41 outfoxxed[m]: And copy_with_damage is now implicit in the new protocol?
10:42 any1: yes
10:42 outfoxxed[m]: thanks
11:06 outfoxxed[m]: Is capture_frame::failure_reason::unknown supposed to indicate you should try again? (compared to stopped)
11:06 emersion: nope
11:06 emersion: or, well
11:07 emersion: not ad vitam eternam
11:07 outfoxxed[m]: I'll just do the same thing as stopped() then I guess
11:13 outfoxxed[m]: was capture_output_region just removed?
11:14 any1: not included, yes
11:18 any1: The user can just crop the image afterwards. Some tips for optimising: instersect damage with the region of interest before capturing. Instead of copying to a new buffer when cropping, just change width height and origin, but keep the stride the same
11:19 outfoxxed[m]: It's not too much of an issue for my client currently. I'm just implementing taskbar window previews and such.
11:20 outfoxxed[m]: Has there been any discussion about a workspace capture source?
11:20 any1: probably. Cosmic might have that
11:21 outfoxxed[m]: Cosmic does, via a private protocol
11:22 outfoxxed[m]: https://wayland.app/protocols/cosmic-image-source-unstable-v1#zcosmic_workspace_image_source_manager_v1
11:23 outfoxxed[m]: would the right direction here be to open an MR to w-p?
11:24 any1: yes
11:26 emersion: we were missing the workspace protocol, now it's standardized
11:27 outfoxxed[m]: Thats why I was bringing it up here instead of going directly to implementing a private hyprland protocol for it.
11:27 any1: I imagine that you might also benefit from downscaling during capture
11:27 any1: (for your usecase)
11:27 outfoxxed[m]: I haven't figured out how to do that with an egl image yet
11:27 outfoxxed[m]: but yes
11:28 any1: That's not in the protocol, but I think that it should be added at some point.
11:28 any1: emersion: do you agree?
11:29 outfoxxed[m]: assuming there's some way other than sampling the image into another texture with a shader
11:29 outfoxxed[m]: It would be useful yes
11:29 wlb: weston Issue #507 closed \o/ (Output to a specific display among multiple displays https://gitlab.freedesktop.org/wayland/weston/-/issues/507)
11:29 emersion: any1: unsure. don't want to turn it into a general image manipulation protocol
11:30 outfoxxed[m]: Do you have thoughts on an exclude_layers parameter for workspace capture? I'd find that useful for the workspace previews case. It would instruct the compositor to exclude layers and layer popups from the capture, making the previews use case look a lot cleaner
11:31 outfoxxed[m]: Or was ext-layer-shell not merged yet
11:31 outfoxxed[m]: I'm not sure if ext protocols are allowed to talk about protocols outside of w-p
11:32 any1: emersion: I guess that a preview thing doesn't desperately need downsampling because you don't have to capture at a very high rate. However, I did actually patch wlr-screencopy-v1 to downscale during capture for an embedded device. It made a lot of difference for that particular usecase (capturing 4k and downscaling to 1080p for encoding and streaming)
11:33 emersion: that is better achieved with zero copy access imho
11:33 emersion: then the user can do arbitrary transforms
11:33 outfoxxed[m]: At least for performance on a desktop, I've captured upwards of 10 reasonably sized windows at once with no hits
11:33 outfoxxed[m]: via linux-dmabuf, not shm of course
11:34 outfoxxed[m]: emersion: Is there a protocol for creating buffers like this?
11:34 any1: emersion: sure, but it's much harder to implement. :)
11:35 outfoxxed[m]: or do you mean zero copy, after the initial copy out of the compositor
11:38 any1: There is a wlr protocol named wlr-export-dmabuf, but I think that it's fundamentally broken and would not recommend it.
11:40 outfoxxed[m]: Is the goal of this one to export a read only dmabuf containing the output to a client instead of the client giving the compositor a buffer to copy into?
11:40 any1: yes
11:40 outfoxxed[m]: And is the fundamenally broken part due to the compositor being able to reuse the dmabuf at some point or something else?
11:40 any1: almost
11:41 any1: I mean, you're on the right track. The problem is actually the reverse
11:41 outfoxxed[m]: It can never reclaim the dmabufs?
11:41 outfoxxed[m]: and runs out of memory?
11:41 any1: The compositor doesn't care. It just reuses them regardless
11:42 outfoxxed[m]: It doesn't wait till destroy()?
11:42 outfoxxed[m]: I mean it seems potentially broken in both cases but that would be less broken
11:42 any1: Yes, leasing the buffer to the client would also be broken because the client could potentially hold onto buffers forever
11:43 outfoxxed[m]: The difference being that it would be the compositor that OOMs instead of the client if this were to happen?
11:43 outfoxxed[m]: vs if you were to just send a bunch of wl_buffers
11:43 any1: yes
11:44 outfoxxed[m]: is there a way to pass ownership of the buffer to the client, or would that require extra code in the kernel?
11:44 outfoxxed[m]: e.g. if the client doesn't release the buffer in time, give it ownership of the buffer and make a new one
11:47 any1: I don't think that it matters as far as the kernel is concerned. It would probably work fine to put some limits on how many buffers the client can hold at a time and/or for how long.
11:48 outfoxxed[m]: Then you get into issues like the client opening multiple connections though
11:48 outfoxxed[m]: Maybe something like an event saying the compositor is forcibly reclaiming the buffer because you took too long to release it would work?
11:48 any1: I think that we're not trying to protect against malicious clients, but rather buggy ones
11:49 outfoxxed[m]: Seems like it would be better if clients couldn't OOM or freeze the compositor at all, if possible though
11:51 outfoxxed[m]: but yes for a privileged protocol it would be nice to start with "the clients aren't malicious"
11:51 any1: Well, a client can deplete all the video memory regardless, but the compositor pre-allocates some buffers for its swap chain
11:52 outfoxxed[m]: In this case we're kind of taking over the swapchain though
11:52 any1: But, if the compositor constantly needs to allocate new buffers to send to the client that would allow for buggy clients to lock things up.
11:54 any1: So, I guess, putting some limits and making sure that the compositor always has at least 2 buffers in its swap chain would make buffer leasing work
11:54 outfoxxed[m]: Maybe this is the wrong perspective to look at it from in the first place. If we're making the compositor allocate more buffers to give a client the old one, that's not much better than making the client allocate and the compositor copy
11:55 any1: It would also be using those same buffers for scanout
11:55 outfoxxed[m]: It removes the copy, but it seems like the biggest thing this is trying to avoid is vram usage
11:55 outfoxxed[m]: Combined and on an embedded device that probably has some impact, but I have no idea how much
11:56 any1: conserving memory bandwidth makes a big difference on embedded
11:59 any1: Anyhow, I would recommend implementing image-copy-capture before going down that path
12:00 outfoxxed[m]: I've implemented the client, though I still need to go build wlr/sway to make sure output capture works
12:01 outfoxxed[m]: also wondering, why is it not possible to compare dev_t values for dmabuf devices?
12:02 outfoxxed[m]: and is it only == comparisons that may not work or is != also unreliable
12:03 any1: I was not aware that you could not compare them
12:03 outfoxxed[m]: The protocols all say you cant, in practice hyprland sends the same value every time, though I assume other compositors dont
12:04 outfoxxed[m]: Currently I look up the render node for the dev_t and compare its path instead of the dev_t itself
12:04 any1: Well, I guess I'm doing it wrong then. :p
12:05 zamundaaa[m]: Comparing the path is also wronh
12:05 outfoxxed[m]: wait what?
12:05 zamundaaa[m]: dev_t tells you the node, not the underlying device
12:05 outfoxxed[m]: How are you supposed to compare them?
12:05 any1: how indeed
12:05 zamundaaa[m]: As long as you look up the render node, using the dev_t should be the correct way
12:06 zamundaaa[m]: But you can also just use the libdrm function for this purpose
12:07 outfoxxed[m]: which one? and what do you mean by "using the dev_t"? As in, in an ==/!= comparison or something else?
12:08 zamundaaa[m]: Just == comparison
12:08 any1: phew. I'm doing it right after all
12:09 outfoxxed[m]: but for !=, at least the path to the render node has to be looked up?
12:09 outfoxxed[m]: I'm creating a gbm device from the render node so I can't see how that comparsion would be wrong at least
12:10 outfoxxed[m]: unless its available at multiple paths
12:12 any1: Maybe I'm missing something from the equation, but a != b is the same as !(a == b), so ...
12:13 outfoxxed[m]: from what I understand so far, two different dev_t values may point to the same device, but the same dev_t value can't point to a different device over the lifetime of the process
12:13 outfoxxed[m]: so you can use an == comparison as a hot-path
12:15 zamundaaa[m]: Two dev_t should definitely point to the same device
12:16 zamundaaa[m]: The only caveat is that the compositor might send a dev_t to a KMS node rather than a render node
12:16 outfoxxed[m]: so if the compositor sends a dev_t pointing to a render node, and then later one pointing to a KMS node, then the dev_t values would be not equal but the looked up render nodes equal
12:17 outfoxxed[m]: which as far as I understand is what I described
12:17 outfoxxed[m]: The kms node is /dev/dri/cardX instead of /dev/dri/renderDXXX right?
12:17 zamundaaa[m]: Yes
12:17 zamundaaa[m]: But you can have multiple paths pointing to the same underlying device
12:18 zamundaaa[m]: Like /dev/dri/renderD128 vs /dev/dri/by-path/...
12:18 outfoxxed[m]: does getting the absolute/canonical (I forget which is which) path of the node solve this?
12:19 outfoxxed[m]: canonical
12:19 zamundaaa[m]: Not sure it always works. But it also doesn't matter if you start out with a dev_t anyways... just compare the dev_t
12:20 outfoxxed[m]: What if you're sent a KMS and then a render node, or vice versa?
12:20 outfoxxed[m]: I'd find it surprising if that actually happened in practice though
12:21 linkmauve: “13:13:14 outfoxxed[m]> from what I understand so far, […] the same dev_t value can't point to a different device over the lifetime of the process”, this is possible actually, for instance with GPU hotplug, or during the boot process.
12:22 outfoxxed[m]: In that case wouldn't you end up with the same kms/render node names as well and no way to tell them apart?
12:23 any1: The compositor is probably going to send you a "stopped" event if you unplug
12:23 outfoxxed[m]: I have a global map of dev_t+render node path pairs to gbm_device pointers as is
12:24 outfoxxed[m]: as far as I'm aware I'm supposed to keep the gbm device live for the duration of the buffer so they're all refcounted based on live buffers using them
12:24 outfoxxed[m]: I guess in the case that they all stop that fixes itself though
12:26 any1: Nobody tests GPU hotplug anyway. :p
12:26 outfoxxed[m]: is that even supposed to work at all outside of external gpus?
12:28 any1: I'd just put a // TODO: Test and figure out GPU hotplug. ;)
12:29 outfoxxed[m]: realistically its going to crash, the crash handler will catch it, and it will restart itself in half a second
12:29 outfoxxed[m]: and I have no way to test it
12:29 outfoxxed[m]: so I don't care that much
12:30 zamundaaa[m]: outfoxxed: you misunderstood. I meant that you should get the render node and then compare the dev_t from that
12:30 zamundaaa[m]: any1: I do
12:31 outfoxxed[m]: zamundaaa[m]: is there a libdrm function for that?
12:31 any1: No true scotsman tests GPU hotplug anyway!
12:32 outfoxxed[m]: outfoxxed[m]: I'm only in as deep as "read-through-three-other-programs-that-create-dmabufs-and-hack-something-together" at this point so I'm not super familiar with it
12:35 zamundaaa[m]: outfoxxed: drmDevicesEqual should work for that
12:35 zamundaaa[m]: Not 100% sure though
13:10 outfoxxed[m]:uploaded an image: (26KiB) < https://matrix.org/oftc/media/v1/media/download/AcPOC878qvTmO-jLAo3pasLXobRUuR-LVfx36LkFQ9Dk3c6vEfX_1XXRNbkK1dpJXHYTCPh6gYXWDIoT_S7uR71CeUp-IlkAAG91dGZveHhlZC5tZS9ta2FRcnpEYWp1blpvd3hIY294Tm5Gdm4 >
13:10 outfoxxed[m]: am I supposed to damage_buffer between captures?
13:11 any1: Yeah, if you have more than 1 buffer
13:11 outfoxxed[m]: appears to do it
13:12 outfoxxed[m]: I use a swapchain of 2 buffers, but what does having exactly one do differently here?
13:12 emersion: any1: i don't think it's a lot more complicated server-side, it's easy client-side, and there is https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/121
13:16 any1: outfoxxed[m]: The compositor only updates the region that changed unless you tell it to update other parts too. If you have one frame, that frame is always up to date with the compositor.
13:16 any1: If you have 2, one of them will be missing the last update
13:17 outfoxxed[m]: ah makes sense
13:17 outfoxxed[m]: the compositor is still allowed to modify more than that if it doesn't have a more efficient rendering process for the damage region right
13:18 any1: correct
13:18 any1: emersion: ok, let's merge that then. :)
13:22 any1: emersion: Although, how do we handle hardware planes and how is the client supposed to deal with funky modifiers that resist encoding, like e.g. fbc?
13:23 emersion: there are multiple possible strategies w/ hw planes
13:23 emersion: one is to use hw planes and blit to a separate buffer just for capture
13:23 emersion: one is to disable hw planes during capture
13:23 emersion: one is to use writeback connectors
13:24 emersion: second one is what happens with the wlroots cursor atm
13:24 any1: You might be able to use writeback with image-copy-capture also, right?
13:25 emersion: depends if the client submits a compatible buffer
13:25 any1: or the compositor could set the constraints to match
13:26 emersion: yeah, but that still could be not enough
13:26 emersion: (allocation constraints implied by USE_SCANOUT)
13:26 any1: ahh
13:26 emersion: more generally writeback commits could fail for pretty much arbitrary hw limitations
13:27 emersion: so we'd always need a fallback path
13:27 emersion: (e.g. maybe a YUV surface is displayed on odd coords on Intel so it just refuses to do the thing)
13:28 any1: I suppose we could also disable compression during capturing
13:55 jadahl: bl4ckb0ne: are you the the one who gave RB of w-p!367 ?
13:56 vyivel: jadahl: seems so? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/367#note_2707407
13:57 jadahl: thats an ACK
13:57 jadahl: which is why I'm uncertain
13:57 vyivel: ah mb
13:57 jadahl: the /reviewer change makes me suspect it's the case though
14:12 bl4ckb0ne: sorry, ill make it more clear next time
14:20 jadahl: bl4ckb0ne: so that's a yes?
14:20 bl4ckb0ne: yes
14:43 wlb: wayland-protocols/main: James Ramsey * ext-idle-notify: Allow for the ignoring of idle inhibitors https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/20bcf732a9a1 staging/ext-idle-notify/ext-idle-notify-v1.xml
14:43 wlb: wayland-protocols Merge request !367 merged \o/ (ext-idle-notify: amend to work properly with apps for mitigating RSI https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/367)
15:07 Consolatis: jadahl: thanks for merging
15:10 wlb: weston/main: Colin Kinloch * clients/fullscreen: Add option to map window fullscreen https://gitlab.freedesktop.org/wayland/weston/commit/0aeb8e59104f clients/fullscreen.c
15:10 wlb: weston/main: Colin Kinloch * clients/window: Save pending allocation if mapping fullscreen https://gitlab.freedesktop.org/wayland/weston/commit/5aae333bbbb6 clients/window.c
15:10 wlb: weston Merge request !1668 merged \o/ (clients/fullscreen: Add option to map window fullscreen https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1668)
15:12 jadahl: Consolatis: np
16:13 wlb: weston/main: Leo Li * backend-drm: Use plane's zpos_min to check for underlay ability https://gitlab.freedesktop.org/wayland/weston/commit/ca894ab44f2f libweston/backend-drm/ drm-internal.h drm.c state-propose.c
16:13 wlb: weston/main: Leo Li * backend-drm: Rename mm_has_underlay to mm_underlay_only https://gitlab.freedesktop.org/wayland/weston/commit/89f77176b6b8 libweston/backend-drm/state-propose.c
16:13 wlb: weston Merge request !1586 merged \o/ (backend-drm: Use plane's zpos_min to check for underlay ability https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1586)
22:57 outfoxxed[m]: <any1> "If you have 2, one of them..." <- if buffer size changes, requiring creation of new buffers, should both the front and back buffer request full damage?
23:02 outfoxxed[m]: I currently assume that to be the case, but don't have a compositor to test against for it
23:02 outfoxxed[m]:sent a cpp code block: https://matrix.org/oftc/media/v1/media/download/ASu_E5jXQ78rEJ8uPVc5m4P7vBb2CyGW0XMVZAMHHdIj-WUDI46VQl9_wqYEBC-CJ5h62M3U78TBQJ_bR-YtWuhCeUqgB7GwAG1hdHJpeC5vcmcvbmtZUldkYmdjSUFjTEFGZUhUVVZrbXRZ