ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
lsd|2|2 has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Quit: Konversation terminated!]
<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?
<emersion>
your messages don't get through properly
<emersion>
all the constraints are re-sent iirc
<outfoxxed[m]>
is this a matrix-irc bridge issue?
<emersion>
they get linkified
<outfoxxed[m]>
thats unfortunate
<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?
<emersion>
yea
<outfoxxed[m]>
And copy_with_damage is now implicit in the new protocol?
<any1>
yes
<outfoxxed[m]>
thanks
<outfoxxed[m]>
Is capture_frame::failure_reason::unknown supposed to indicate you should try again? (compared to stopped)
<emersion>
nope
<emersion>
or, well
<emersion>
not ad vitam eternam
<outfoxxed[m]>
I'll just do the same thing as stopped() then I guess
<outfoxxed[m]>
was capture_output_region just removed?
<any1>
not included, yes
fmuellner has joined #wayland
<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
<outfoxxed[m]>
It's not too much of an issue for my client currently. I'm just implementing taskbar window previews and such.
<outfoxxed[m]>
Has there been any discussion about a workspace capture source?
<any1>
probably. Cosmic might have that
<outfoxxed[m]>
Cosmic does, via a private protocol
<emersion>
any1: unsure. don't want to turn it into a general image manipulation protocol
<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
<outfoxxed[m]>
Or was ext-layer-shell not merged yet
<outfoxxed[m]>
I'm not sure if ext protocols are allowed to talk about protocols outside of w-p
<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)
<emersion>
that is better achieved with zero copy access imho
<emersion>
then the user can do arbitrary transforms
<outfoxxed[m]>
At least for performance on a desktop, I've captured upwards of 10 reasonably sized windows at once with no hits
<outfoxxed[m]>
via linux-dmabuf, not shm of course
<outfoxxed[m]>
emersion: Is there a protocol for creating buffers like this?
<any1>
emersion: sure, but it's much harder to implement. :)
<outfoxxed[m]>
or do you mean zero copy, after the initial copy out of the compositor
<any1>
There is a wlr protocol named wlr-export-dmabuf, but I think that it's fundamentally broken and would not recommend it.
<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?
Moprius has joined #wayland
<any1>
yes
<outfoxxed[m]>
And is the fundamenally broken part due to the compositor being able to reuse the dmabuf at some point or something else?
<any1>
almost
<any1>
I mean, you're on the right track. The problem is actually the reverse
<outfoxxed[m]>
It can never reclaim the dmabufs?
<outfoxxed[m]>
and runs out of memory?
<any1>
The compositor doesn't care. It just reuses them regardless
<outfoxxed[m]>
It doesn't wait till destroy()?
<outfoxxed[m]>
I mean it seems potentially broken in both cases but that would be less broken
<any1>
Yes, leasing the buffer to the client would also be broken because the client could potentially hold onto buffers forever
<outfoxxed[m]>
The difference being that it would be the compositor that OOMs instead of the client if this were to happen?
<outfoxxed[m]>
vs if you were to just send a bunch of wl_buffers
<any1>
yes
<outfoxxed[m]>
is there a way to pass ownership of the buffer to the client, or would that require extra code in the kernel?
<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
<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.
<outfoxxed[m]>
Then you get into issues like the client opening multiple connections though
<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?
<any1>
I think that we're not trying to protect against malicious clients, but rather buggy ones
<outfoxxed[m]>
Seems like it would be better if clients couldn't OOM or freeze the compositor at all, if possible though
<outfoxxed[m]>
but yes for a privileged protocol it would be nice to start with "the clients aren't malicious"
<any1>
Well, a client can deplete all the video memory regardless, but the compositor pre-allocates some buffers for its swap chain
kts has joined #wayland
<outfoxxed[m]>
In this case we're kind of taking over the swapchain though
<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.
<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
<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
<any1>
It would also be using those same buffers for scanout
<outfoxxed[m]>
It removes the copy, but it seems like the biggest thing this is trying to avoid is vram usage
<outfoxxed[m]>
Combined and on an embedded device that probably has some impact, but I have no idea how much
<any1>
conserving memory bandwidth makes a big difference on embedded
<any1>
Anyhow, I would recommend implementing image-copy-capture before going down that path
<outfoxxed[m]>
I've implemented the client, though I still need to go build wlr/sway to make sure output capture works
kts has quit [Quit: Leaving]
<outfoxxed[m]>
also wondering, why is it not possible to compare dev_t values for dmabuf devices?
<outfoxxed[m]>
and is it only == comparisons that may not work or is != also unreliable
<any1>
I was not aware that you could not compare them
<outfoxxed[m]>
The protocols all say you cant, in practice hyprland sends the same value every time, though I assume other compositors dont
<outfoxxed[m]>
Currently I look up the render node for the dev_t and compare its path instead of the dev_t itself
<any1>
Well, I guess I'm doing it wrong then. :p
<zamundaaa[m]>
Comparing the path is also wronh
<outfoxxed[m]>
wait what?
<zamundaaa[m]>
dev_t tells you the node, not the underlying device
<outfoxxed[m]>
How are you supposed to compare them?
<any1>
how indeed
<zamundaaa[m]>
As long as you look up the render node, using the dev_t should be the correct way
<zamundaaa[m]>
But you can also just use the libdrm function for this purpose
feaneron has joined #wayland
<outfoxxed[m]>
which one? and what do you mean by "using the dev_t"? As in, in an ==/!= comparison or something else?
<zamundaaa[m]>
Just == comparison
<any1>
phew. I'm doing it right after all
<outfoxxed[m]>
but for !=, at least the path to the render node has to be looked up?
<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
<outfoxxed[m]>
unless its available at multiple paths
<any1>
Maybe I'm missing something from the equation, but a != b is the same as !(a == b), so ...
<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
<outfoxxed[m]>
so you can use an == comparison as a hot-path
<zamundaaa[m]>
Two dev_t should definitely point to the same device
<zamundaaa[m]>
The only caveat is that the compositor might send a dev_t to a KMS node rather than a render node
<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
<outfoxxed[m]>
which as far as I understand is what I described
<outfoxxed[m]>
The kms node is /dev/dri/cardX instead of /dev/dri/renderDXXX right?
<zamundaaa[m]>
Yes
<zamundaaa[m]>
But you can have multiple paths pointing to the same underlying device
<zamundaaa[m]>
Like /dev/dri/renderD128 vs /dev/dri/by-path/...
<outfoxxed[m]>
does getting the absolute/canonical (I forget which is which) path of the node solve this?
<outfoxxed[m]>
canonical
<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
<outfoxxed[m]>
What if you're sent a KMS and then a render node, or vice versa?
<outfoxxed[m]>
I'd find it surprising if that actually happened in practice though
<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.
<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?
<any1>
The compositor is probably going to send you a "stopped" event if you unplug
<outfoxxed[m]>
I have a global map of dev_t+render node path pairs to gbm_device pointers as is
<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
<outfoxxed[m]>
I guess in the case that they all stop that fixes itself though
<any1>
Nobody tests GPU hotplug anyway. :p
<outfoxxed[m]>
is that even supposed to work at all outside of external gpus?
coldfeet has quit [Quit: Lost terminal]
<any1>
I'd just put a // TODO: Test and figure out GPU hotplug. ;)
<outfoxxed[m]>
realistically its going to crash, the crash handler will catch it, and it will restart itself in half a second
<outfoxxed[m]>
and I have no way to test it
<outfoxxed[m]>
so I don't care that much
<zamundaaa[m]>
outfoxxed: you misunderstood. I meant that you should get the render node and then compare the dev_t from that
<zamundaaa[m]>
any1: I do
<outfoxxed[m]>
zamundaaa[m]: is there a libdrm function for that?
<any1>
No true scotsman tests GPU hotplug anyway!
<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
<zamundaaa[m]>
outfoxxed: drmDevicesEqual should work for that
<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.
<any1>
If you have 2, one of them will be missing the last update
<outfoxxed[m]>
ah makes sense
<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
<any1>
correct
<any1>
emersion: ok, let's merge that then. :)
rgallaispou has joined #wayland
<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?
<emersion>
there are multiple possible strategies w/ hw planes
<emersion>
one is to use hw planes and blit to a separate buffer just for capture
<emersion>
one is to disable hw planes during capture
<emersion>
one is to use writeback connectors
<emersion>
second one is what happens with the wlroots cursor atm
<any1>
You might be able to use writeback with image-copy-capture also, right?
<emersion>
depends if the client submits a compatible buffer
<any1>
or the compositor could set the constraints to match
<emersion>
yeah, but that still could be not enough
<emersion>
(allocation constraints implied by USE_SCANOUT)
<any1>
ahh
<emersion>
more generally writeback commits could fail for pretty much arbitrary hw limitations
<emersion>
so we'd always need a fallback path
<emersion>
(e.g. maybe a YUV surface is displayed on odd coords on Intel so it just refuses to do the thing)
<any1>
I suppose we could also disable compression during capturing
sima has joined #wayland
nerdopolis has joined #wayland
<jadahl>
bl4ckb0ne: are you the the one who gave RB of w-p!367 ?
rgallaispou has quit [Read error: Connection reset by peer]
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #wayland
Tokoyami has quit [Quit: ~@~]
Tokoyami has joined #wayland
feaneron has quit [Quit: feaneron]
CodeSpelunker has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
narodnik2 has quit []
narodnik2 has joined #wayland
kts has quit [Quit: Leaving]
coldfeet has quit [Quit: Lost terminal]
CodeSpelunker has quit [Ping timeout: 480 seconds]
WhizzWr has quit [Quit: Bye!]
WhizzWr has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
lsd|2|2 has joined #wayland
nerdopolis has joined #wayland
<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?
<outfoxxed[m]>
I currently assume that to be the case, but don't have a compositor to test against for it