ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
sally has joined #wayland
<bl4ckb0ne>
thanks for finding it Ermine
alarumbe has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
crazybyte4 has quit [Quit: Bye]
crazybyte4 has joined #wayland
<mstoeckl>
After reading through various issues related to buffer allocation and races for ext-image-copy-capture, I am starting to think that having clients receive image data through `wl_buffer` is a mistake and overextension of the abstraction.
<mstoeckl>
Wayland might be better off with an entirely separate abstraction and object type for compositor-to-client image data transfers. Has anyone experimented with such an approach before?
<danieldg>
is that what wlr export-dmabuf did?
<danieldg>
I do agree it's abusing the interface, but that's from making abstractions on wlr-shm and basically needing to say 'if you have the server write to this, all this logic is useless'
<danieldg>
s/wlr-shm/wl_shm/
feaneron has quit [Ping timeout: 480 seconds]
<mstoeckl>
wlr-export-dmabuf is a good example, thank you; although frame creation is only by user request, and frame objects are single use. One of the things I was thinking of was having the compositor create and maintain a pool of reusable frames, as a sort of inverse of wl_surface/wl_buffer.
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Remote host closed the connection]
<danieldg>
I guess there's an argument about what happens when a client is slow to release a buffer
<danieldg>
if the client provided the buffer, that's only their problem
<danieldg>
but if the server provides it, does it end up consuming resources forever?
alarumbe has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<danieldg>
I guess the server can still limit count of pending buffers, so maybe not a big problem
Flat_ has joined #wayland
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
Flat has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
RAOF has joined #wayland
alarumbe has joined #wayland
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
aelius has quit [Remote host closed the connection]
<emersion>
mstoeckl: why is that? i don't think there are any issues with wl_buffer for copies
<emersion>
mstoeckl: there needs to be parameter negociation for allocation
<emersion>
client-side has the benefits that (1) client can allocate with the API it wants to, e.g. VA-API, to ensure it can use it for the purpose they want (2) memory accounting works
garnacho has joined #wayland
alarumbe has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<mstoeckl>
emersion: Using wl_buffer may require roundtrips when the sizes of recorded sources change; the ideal parameters (acceptable modifiers, maximum sizes) to receive data may also differ from those to send data.
any1_ has quit [Remote host closed the connection]
any1 has joined #wayland
<mstoeckl>
If the client had way to communicate to the compositor what DMABUFs it prefers, like a mirror image of linux-dmabuf feedback, then it would have benefit (1) without requiring a roundtrip whenever source properties change
nerdopolis has joined #wayland
<mstoeckl>
Admittedly, this would be quite complicated. I haven't looked into (2), memory accounting, in detail and how that differs for shared memory vs. DMABUFS. If the compositor sub-allocates all shared memory frame data for screen captures from a single memory region, then even naive/first-touch accounting shouldn't be an issue since shared memory region ownership is not moving.
<MrCooper>
at the end of the day, either process can keep buffers shared between the compositor and clients alive, so not sure which one happens to allocate them really matters that much for accounting
<MrCooper>
mstoeckl: FWIW, I think capturing via portal + pipewire works kind of like you describe
<pq>
mstoeckl, FWIW, linux_dmabuf, too, requires a roundtrip on allocation (create_immed is fragile and therefore not a good idea).
<pq>
so a roundtrip on allocation, no matter who allocates, seems like a requirement
gradientofraster has joined #wayland
<pq>
The fundamental difference is read vs. write. Not all readable formats are writable, which probably warrants another interface than linux_dmabuf.
tokyovigilante has quit [Ping timeout: 480 seconds]
tokyovigilante has joined #wayland
gradientofraster has quit [Remote host closed the connection]
<mstoeckl>
I very much would want create_immed to not be fragile; in the programs I've seen, roundtrips tend interact to badly with function-based program logic encapsulation, with multiple roundtrips sometimes being serially instead of parallely.
<mstoeckl>
(With a proper program design multiple roundtrips can be done in parallel, of course.)
kts has joined #wayland
<MrCooper>
at least we don't have something like libX11 which makes avoiding serialized round-trips hard to impossible :)
leon-anavi has quit [Remote host closed the connection]
<nickdiego[m]>
is fractional-scale-v1's preferred_scale event supposed to be sent as part of xdg-surface configure events (when the target wl_surface is associated to a xdg surface) ?
gradientofraster has joined #wayland
gradientofraster has quit [Remote host closed the connection]
<davidre>
I would say no, since you can create fractional scale for non xdg surfaces
<davidre>
Or it would be special case for xdg shell
<nickdiego[m]>
yeah I see, was thinking of it as a potential optimization as scale changes may lead to configure events too I guess
<zzag>
nickdiego[m]: fwiw, with kwin, it's always guaranteed that the preferred scale event is part of a configure sequence
<zzag>
but unfortunately no client can rely on it
yrlf has joined #wayland
kasper93_ has joined #wayland
kasper93 is now known as Guest13653
kasper93_ is now known as kasper93
kasper93_ has joined #wayland
kasper93 is now known as Guest13654
kasper93_ is now known as kasper93
Guest13653 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
the timing is intended to be the same as preferred_buffer_scale on wl_surface, which currently happens independently of configure.
kasper93_ has joined #wayland
kasper93 is now known as Guest13655
kasper93_ is now known as kasper93
<kennylevinsen>
There is some semantic difference (a configure is a new state that must be accepted and ack'ed, this is an optional change of compositor preference), but still an upgrade over the entirely out-of-band approach we had before with clients manually tracking wl_outputs...
kasper93_ has joined #wayland
kasper93 is now known as Guest13656
kasper93_ is now known as kasper93
Guest13654 has quit [Ping timeout: 480 seconds]
Guest13655 has quit [Ping timeout: 480 seconds]
Guest13656 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
fangzhoug has quit [Remote host closed the connection]
fangzhoug has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
fangzhoug has quit [Read error: Connection reset by peer]
<nickdiego[m]>
> a configure is a new state that must be accepted and ack'ed, this is an optional change of compositor preference
<nickdiego[m]>
shouldn't that be the case for preferred_scale too?
<kennylevinsen>
nickdiego[m]: so far, clients have decided the scale themselves and have not been required to support hidpi
<kennylevinsen>
preferred_buffer_scale just replaces a system where a client wanting hidpi operation would have to guess the best scale on its own
<nickdiego[m]>
I mean, they also need to "ack" whey they apply it, but currently through wp-viewport, right?
<kennylevinsen>
(and unless the MR vyivel links is merged, there is not configure event that core wl_surface events can tie into)
<vyivel>
is there an xdg-desktop-portal backend that uses ext-image-copy-capture-v1 for (window) capturing?
<orowith2os[m]>
vyivel: not yet, but I've been wanting to hack one up that uses toplevel-list
<vyivel>
nice
<vyivel>
could also add support to xdg-desktop-portal-wlr (with some external gui source chooser)
<orowith2os[m]>
I don't have any opinions on what to use with it, I suppose being scriptable would do the job. Put out some json, some pipewire nodes that link to each toplevel, and let software do what it wants
<orowith2os[m]>
oh, weird. I just figured out that the gnome-shell recording feature doesn't work with windows.
<orowith2os[m]>
well, anyways, my focus right now is figuring out how to use calloop with wayland-rs.
<orowith2os[m]>
One too many burns with C/C++.
<llyyr>
vyivel: I don't think there's any implementation of ext_foreign_toplevel_image_capture_source_manager_v1 written yet