ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
glennk has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
tlwoerner has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
FreeFull has quit []
crazybyte4 has quit [Read error: Connection reset by peer]
crazybyte4 has joined #wayland
Tarnyko has quit [Read error: Connection reset by peer]
<vyivel>
in ext-workspace-v1, can an output belong to multiple workspace groups?
<vyivel>
i don't see anything prohibiting it but not sure if it's intentionally allowed
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
sima has joined #wayland
tzimmermann has joined #wayland
<zzag>
jadahl: the "read only" banner is gone. can we have a new w-p release some time soon? 🙃
garnacho has joined #wayland
kts has joined #wayland
<Drakulix>
vyivel: I believe the intention was to support that for tiling compositors using tags and allowing to display multiple tags on the same output.
<Drakulix>
But to be sure, I would also have to read through all the comments on the protocols MR again..
<jadahl>
zzag: ah, great
<kchibisov>
For wayland event loop to integrate with some external event loop, you'd need to call wl_display_prepare_read_queue, before going to sleep. That implies that each toolkit would need to expose its `wl_event_queue` somehow (to check if we have events enqueued from other threads). However if `wl_display_prepare_read_queue` could fail if someone on the same thread called it (basically state in TLS), it could integrate simelessly(at least I think
<kchibisov>
so) if upon exiting from library, the library would call prepare_read itself. External loop (if it was wayland one) would fail, and if taking guard failed in library it'll indicate that it needs to re-dispatched. The existing code that calls on the `prepare_read` on the same thread is pretty much broken anyway, since it deadlocks, so maybe altering is not that bad?
<pq>
kchibisov, are you replying to something ooor?
<kchibisov>
asking.
<kchibisov>
To simplify. User has an Event Loop. It calls my wayland event loop from the same thread and then goes blocking.
<kchibisov>
User has also some code that runs the default prepara_read event loop on other thread.
<kchibisov>
To know, whether user in its event loop need to wake-up immidiately they'd need to call prepare_read of my library before they go back to `poll`.
<pq>
I think a toolkit that has its own event loop should offer the event loop integration API in general, and not special-case wayland-client.
<kchibisov>
Since just e.g. put fd into their epoll won't work.
<kchibisov>
However, if my library will call `prepare_read` before returning control back to external event loop and tell that it should wake-up it'll mostly work.
<kchibisov>
Mostly is that if external loop also does wayland reading, it'll block.
<kchibisov>
So, one way to avoid that is to make `prepare_read` fail due to TLS state that same thread already called it.
<kchibisov>
Right now such code will deadlock, so I asked if tuning it a bit is possible.
<kchibisov>
The problem is e.g. game engines, etc, which have their own event loop, and generally, just _poll_ wayland stuff occasionally. So e.g. your windowing library is not in charge of the loop.
<kchibisov>
deadlock is due to read_events waiting on condvar to reach count of `0`, but because you called it twice on the same loop it won't ever make it.
<kchibisov>
on the same thread*
<pq>
So the fundamental problem is that one might prepare_read twice from the same thread, before actually reading. Reading will block, because the last intention to read cannot proceed to reading due to being in the same thread.
<pq>
prepare_read twice from the same thread seems like a bug always, so I think you have a solid case. We'll ignore the possibility of passing the "context" to another thread for the actual read.
<kchibisov>
yeah, but if you have a lot of layers, it could be _tricky_.
<pq>
Do we use TLS for anything in libwayland-client yet?
<kchibisov>
I think the issue is cancecl_read as well, since you can cancel other thread.
<kchibisov>
but maybe it's not a big issue.
<kchibisov>
like if you just call cancel_read you have a chance of canceling read intent of others thread.
<pq>
You want to ensure that both prepare_read and read/cancel always happen in the same thread?
<kchibisov>
I want prepare_read to fail if someone already called it on the same thread.
<pq>
yes, that's you goal 1, what about goal2?
<kchibisov>
And `cancel_read` to only decrement if current thread called `prepare_read`.
<pq>
oh, that sounds nasty
<kchibisov>
I want 1, 2 I just noticed.
<kchibisov>
since thread 1 calls prepare_read, but thread 2 for whatever reason called cancel_read, it'll mess up everything pretty much.
<kchibisov>
I think other issue is if you call `cancel_read`, but then `read_events`, it'll deadlock.
<kchibisov>
Though, I could be wrong about that, I'm not that strong with wayland internals, but given that we pass `*wl_display` around, I think that's how it works.
<pq>
Clients written so far tend to call prepare_read in a loop until it succeeds. They would end us busy-deadlocking on prepare_read instead of deadlocking on read, no?
iomari891 has joined #wayland
<kchibisov>
Ah, because of the dispatch_pending_loop....
<kchibisov>
since it implies that you try until you make it.
<pq>
All this should be in a libwayland issue, this is running out of IRC.
<kchibisov>
yeah, I'll open one, I was curious what should be done here in general, since integrating your event loop into external event loop, is a bit more than just put your epoll into other's epoll.
<pq>
kchibisov, would it help to have a rule of thumb that if someone passes you a wl_display then you must not prepare_read unless you move it to a separate thread, and if you created the wl_display then you should prepare_read & read on it? But this applies only to event loop integration. If my call is blocking, then I can prepare_read & read, but I must not be called from an event loop prepare-to-block vfunc.
<kchibisov>
the problem is when you have other thread doing blocking reads.
<pq>
why? They are their own threads, so how'd they deadlock?
<pq>
do you mean cross-thread synchronous calls?
<kchibisov>
if other thread will read and enqueue events for you, you won't know that in your external loop.
<kchibisov>
unless you call `wl_display_prepare_read` on the library's event_queue.
<pq>
Why is that a problem?
<kchibisov>
you'll just not wake-up when you have events, and you can block for a while due to that.
<kchibisov>
since you usually wait for READ readiness, but it got read by other thread, so you don't know that.
<pq>
right, and the prepare_read dance is a solution to that, but in this case it fails because..?
<kchibisov>
If you expose all wl_event_queue's from libraries you're using to the outer most event loop there's no problem, other than being really ugly.
<kchibisov>
on the same thread, I mean.
<pq>
but you just said "other thread"?
<kchibisov>
keep in mind, that outer most event loop doesn't do any wayland in my case, so it wasn't the one creating wl_display, etc, etc.
<kchibisov>
I have |thread_1: while (wait_for_event) { winit.poll_events();(does the prepare_read dance) } ; thread_2; clipboard.run(); // does this prepare read dance.
<kchibisov>
by the time I go from poll_events() back to `wait_for_event` clipboard could have enqueued events for winit's queue.
<kchibisov>
so I won't wake-up due to READ, because clipboard already did so, so I'll be waiting for another event to arrive, while I already have some.
<kchibisov>
To solve this, I'd need to call `prepare_read` right when I exit from `poll_events()` in winit.
<kchibisov>
But if my while(wait_for_event) loop had its own wayland stuff it could block.
<pq>
The blocking poll() syscall is part of the prepare_read dance, right? Done in both threads?
<kchibisov>
yeah.
<kchibisov>
The problem is external loop, that doesn't know about that semantic.
<kchibisov>
since for all of that to work, prepare_read must be called before going to sleep in external event loop as well, which doesn't even know about wayland.
<pq>
That's what event loop integration interfaces should be for.
<kchibisov>
yeah, and I could as a library say that `you must not do a blocking poll`.
<pq>
no, why?
<kchibisov>
I mean, if I call `prepare_read` right when I exit from `poll_events()` I know for sure if I have events or not.
<kchibisov>
And even if I don't, the `epoll` waiting for readiness will be _sound_, since other thread won't be able to read.
<pq>
I have a very specific model of event loop integration interface in mind, I think Glib has it...
<kchibisov>
do you integrate into glib or you integrate glib into something?
<kchibisov>
There's no issue if integrate into the wayland loop, the problem when you put your wayland loop into some other loop.
<pq>
Shouldn't matter, I assume the interface is good in both directions when implemented by both components.
<kchibisov>
Yeah, I guess my issue is the convinience of how it's usually done.
<pq>
you could always add moar threads :-p
<kchibisov>
it's indeed an option.
<kchibisov>
it's just, if prepare_read failed if someone called it on the same thread, I think it'll just work.
<kchibisov>
Though, the existing assumption that you must re-try kind of breaks it a bit.
<kchibisov>
Though, if you have a destinct error code for `AlreadyCalled`, library can adjust to that.
<kchibisov>
it won't change anything that is existing, but new code can check for e.g. `-2` and know that something called it on this thread already, and instead of polling, it'll just repeat its iteration.
<kchibisov>
repeat iteration of calling to other external libs, etc, etc, since they are the ones calling `prepare_read`.
<kchibisov>
Oh, actually, if you instead of making it an error, make it so prepare_read only increments once on the calling thread, and subsequent call on the same thread doesn't fail, but doesn't increment it either, it'll make existing loops work.
<kchibisov>
Since it doesn't matter who will call read_events on the same thread.
<pq>
I'm not sure what to think of it. I'd prefer either full-blown event loop integration, or if one cannot do that then hack around with more threads. Doing a mixture of them with trial-and-no-harm-done could lead to rare mysterious problems when the safety net fails under conditions that were never foreseen.
<pq>
I won't object, though, if others are happy.
<kchibisov>
I think if prepare_read calls on the same thread won't do extra anything unless you call `read_events`/`cancel_read` on the same thread, it won't change much, other than avoid deadlock.
<kchibisov>
since you won't have a new error case.
<kchibisov>
and who calls the `read_events` doesn't really matter as long as it's on the same thread.
<pq>
It allows sloppy code though, where problem could be hidden deeper by adding more redundant calls.
<kchibisov>
I'll open for discussion at least.
<pq>
sure, this is just my personal opinion, and I'm not gatekeeping
<kchibisov>
I'm not against involved event loop integrations, but if you e.g. have multiple windowing libs, etc, etc, as backends in your engine it becomes messy.
<pq>
if every lib did it the same way...
<kchibisov>
well, it's all nice when you can just put epoll into epoll.
<kchibisov>
but with wayland such trick doesn't really work.
<pq>
why does it work elsewhere? Is it because Wayland uses blocking readmsg() while others use non-blocking?
<kchibisov>
you usually don't share the same fd across multiple threads.
<pq>
maybe blocking readmsg() was the reason for the prepare_read thing in the first place.
<pq>
you don't?
<pq>
how do you achieve reading as needed?
<kchibisov>
I mean, you just have it dedicated to its own thread, having multiple readers from the same connection is not that common.
<kchibisov>
though, I could be wrong.
<pq>
and instead of the fd, you'd use condvars to wake up any thread waiting?
<kchibisov>
I really can not think of a case where you'd spawn more threads to read from the same fd, just to do different things.
<kchibisov>
in X11 world, we were just opening more connections.
<pq>
I think you could do that with Wayland, too. You just get to arrange the cross-thread message yourself: go run your wl_display_dispatch_queue_pending() now.
<kchibisov>
yeah, but you need to tell somehow to bind new stuff.
<pq>
What for?
<kchibisov>
Hm, true, you can do that yourself.
<kchibisov>
though, such interface must be supported by all libraries you're using, including mesa.
<pq>
When ever the reading thread does a cycle, it could broadcast a message "I read" to everyone interested. The other threads would be interested if they have their own wl_event_queue and do only dispatch_pending().
mvlad has joined #wayland
<kchibisov>
the problem is that roundtrip is very common.
<kchibisov>
when you setup your lib to deal with registry, etc.
<pq>
roundtrip is a bug if called from any other context that the default wl_event_queue one.
<pq>
yeah, all components would need to cooperate
<kchibisov>
yeah, it's just I understand that it's possible, but reality is what we have.
<pq>
those that don't cooperate will need their guaranteed own thread I guess
<pq>
which also removes the need to integrate event loops