ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
moa has quit []
bluebugs has joined #wayland
Seirdy_ has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Seirdy_ has quit [Ping timeout: 480 seconds]
Seirdy_ has joined #wayland
pnowack has quit [Quit: pnowack]
Nulo has joined #wayland
<Nulo>
Hey, where can I find manual info about methods like zwlr_layer_surface_v1_set_exclusive_zone?
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
cyberpear has joined #wayland
gryffus has quit [Remote host closed the connection]
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
<zubzub>
eey my PR got reviewed \o/
<zubzub>
and here I was thinking it would probably take 1-2 years
kzw has joined #wayland
<zubzub>
thanks ManMower!
<pq>
if it was up to me, it probably would have :-p
<ManMower>
ugh, I reviewed it early?
<pq>
(no idea what MR this is about, I'm still in the process of skipping MRs from the holiday season)
<ManMower>
I think it was a fix for a nasty problem with external references...
* ManMower
looks it up
<ManMower>
zubzub: do you have an opinion on my perhaps dubious counter proposal?
kzw has quit [Quit: Page closed]
<ManMower>
wayland MR 191 for anyone trying to follow :)
<zubzub>
ManMower: I don't really get what you mean with your proposal (admitted I havent researched it either)
Major_Biscuit has quit [Ping timeout: 480 seconds]
<zubzub>
"But this puts the onus on the compositor to not access buffers created while it's holding external references.
<zubzub>
Is that constraint unreasonable?"
<ManMower>
well I think the root of the problem you're facing is that when the pool resize is deferred, libwayland won't allow a new buffer to be created at the end of it. however, there's no reason to prevent that (and the change I suggested will allow it - the buffer can be created with the "new size"). however, that buffer will be poison until the ext refs are dropped and the pool is actually resized.
<ManMower>
in my mind, the render thread Should Not touch that new buffer in its current pass, and should drop the ext ref before doing anything that needs the new buffer's content
evon has joined #wayland
<ManMower>
but I'm not sure if what's in my mind has any bearing on reality
<ManMower>
so what I'm suggesting is that "compositors can't touch any buffers created from a pool with ext refs until all those ext refs have been dropped"
evon has quit [Killed (NickServ (Too many failed password attempts.))]
evon has joined #wayland
<zubzub>
doesn't that limit the processing of buffers serially? say I have 2 buffers committed shortly after another from the same pool (perhaps a pointer & a toplevel surface?) and both need to be encoded to a video frame by 2 threads
<zubzub>
then one thread has to wait on the other?
<zubzub>
that's the bug that lead me to create this patch
<ManMower>
hehe that leaves me with more questions than answers. hrmmm
ppascher has quit [Ping timeout: 480 seconds]
<ManMower>
when are you taking your ext ref on the pool? when are you dropping it?
<ManMower>
the intended use case when I added ext refs was that an async renderer would build up its scene to render, ref the pools of ever buffer it's going to use in its render thread, cache those pointers, dispatch async render. then on async render completion, drop all the refs. in that world, you would never touch a buffer created by the main thread's dispatch, because it wouldn't be needed until the next
<ManMower>
render pass
<ManMower>
I guess my question is: how are you in a situation where you need to do something with a buffer that your current render pass isn't using as surface content
ppascher has joined #wayland
<zubzub>
my use case is simply encoding buffers on a different thread, one per surface
<zubzub>
no wait its one thread
<dottedmag>
emersion: w.r.t. serials, found the following text in the spec: "The server maintains a monotonically increasing counter for these serial numbers."
<ManMower>
zubzub: how does this thread synchronize with the scene graph?
<ManMower>
how and when do you feed your thread with new buffers
<ManMower>
does your architecture have the typical "we composite the scene every refresh interval" structure?
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
rgallaispou has left #wayland [#wayland]
<zubzub>
ManMower: on the server side the thread has a queue per surface, this thread picks up buffers in a loop and passes them on to gstreamer which may also have it's own internal set of threads per pipeline (there's a gstreamer pipeline per surface)
<zubzub>
once encoded the wayland buffer is unreffed
<zubzub>
then the encoded bytes are send to the client (a compositor running in a browser) where they are composited on the screen
immibis has quit [Read error: Connection reset by peer]
immibis has joined #wayland
<zubzub>
this all worked fine until gtk4 decided to resize its pool which I still had a ref in :P
<zubzub>
anyway, I'll fix the code based on your remarks :)
immibis is now known as Guest492
immibis has joined #wayland
<ManMower>
thanks!
technomancy has left #wayland [ERC (IRC client for Emacs 26.1.50)]
Guest492 has quit [Ping timeout: 480 seconds]
Major_Biscuit has quit [Ping timeout: 480 seconds]
colordrops has joined #wayland
<colordrops>
I've got two external monitors that work from the command line, and can be seen using `hwinfo`, but once Wayland/SwayWM is loaded, only one is seen by wayland and xrandr. If I unplug one, the other becomes visible, and vice versa.
Narrat has joined #wayland
<dottedmag>
colordrops: Please ask in sway channel. Wayland is just a protocol, it cannot be "loaded".
<colordrops>
is wlr-randr part of sway or wayland?
<colordrops>
I was just mentioning sway, but I think it's a wayland issue if I'm not mistaken
<colordrops>
I run wlr-randr --output DP-8 --on and get "failed to apply configuration" unless i first disable the other external monitor, DP-7
<colordrops>
Or are you saying that sway fully implements all of this?
<colordrops>
Sorry for my ignorance
<emersion>
please ask in #sway
<daniels>
(wlr-randr is also part of sway)
<colordrops>
Understood, thank you
<daniels>
in general, Wayland is just a set of conventions which let clients talk to your compositor (such as sway)
<daniels>
actually implementing those conventions - not to mention minor details like actually displaying the final result - is up to each project, which in this case is sway/wlroots
<colordrops>
Ok, I can't believe I've used it this long without understanding that, thanks for the insight
<daniels>
np :)
gryffus has joined #wayland
gryffus_ has joined #wayland
gryffus has quit [Read error: Connection reset by peer]
tzimmermann has quit [Quit: Leaving]
colordrops has quit [Quit: WeeChat 3.1]
colordrops has joined #wayland
jmabr has quit [Remote host closed the connection]