06:10 wlb: wayland-protocols/main: Peter Hutterer * tablet: bump the tablet protocol version https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/23bfdb50df4f stable/tablet/tablet-v2.xml
06:10 wlb: wayland-protocols/main: Peter Hutterer * tablet: add a bustype event to the initial burst of tablet events https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/96c8caa329c1 stable/tablet/tablet-v2.xml
06:10 wlb: wayland-protocols/main: Peter Hutterer * tablet: add support for relative dials https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/8d0a52298b48 stable/tablet/tablet-v2.xml
06:10 wlb: wayland-protocols Merge request !298 merged \o/ (tablet: add support for relative dials https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/298)
06:24 vyivel: in ext-workspace-v1, can an output belong to multiple workspace groups?
06:24 vyivel: i don't see anything prohibiting it but not sure if it's intentionally allowed
07:39 zzag: jadahl: the "read only" banner is gone. can we have a new w-p release some time soon? 🙃
08:16 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.
08:17 Drakulix: But to be sure, I would also have to read through all the comments on the protocols MR again..
08:21 jadahl: zzag: ah, great
08:38 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
08:38 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?
08:40 pq: kchibisov, are you replying to something ooor?
08:40 kchibisov: asking.
08:40 kchibisov: To simplify. User has an Event Loop. It calls my wayland event loop from the same thread and then goes blocking.
08:40 kchibisov: User has also some code that runs the default prepara_read event loop on other thread.
08:41 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`.
08:41 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.
08:42 kchibisov: Since just e.g. put fd into their epoll won't work.
08:42 wlb: wayland-protocols Merge request !387 opened by Jonas Ådahl (jadahl) build: Bump version to 1.42 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/387
08:43 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.
08:43 kchibisov: Mostly is that if external loop also does wayland reading, it'll block.
08:43 kchibisov: So, one way to avoid that is to make `prepare_read` fail due to TLS state that same thread already called it.
08:43 kchibisov: Right now such code will deadlock, so I asked if tuning it a bit is possible.
08:44 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.
08:45 pq: Hmm...
08:45 wlb: wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.42 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/a8d2201f0bc3 meson.build
08:45 wlb: wayland-protocols Merge request !387 merged \o/ (build: Bump version to 1.42 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/387)
08:46 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.
08:46 kchibisov: on the same thread*
08:46 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.
08:46 wlb: wayland-protocols New tag: 1.42 https://gitlab.freedesktop.org/wayland/wayland-protocols/tags/1.42
08:47 kchibisov: yes.
08:48 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.
08:48 kchibisov: yeah, but if you have a lot of layers, it could be _tricky_.
08:48 pq: Do we use TLS for anything in libwayland-client yet?
08:49 kchibisov: I think the issue is cancecl_read as well, since you can cancel other thread.
08:49 kchibisov: but maybe it's not a big issue.
08:49 kchibisov: like if you just call cancel_read you have a chance of canceling read intent of others thread.
08:50 pq: You want to ensure that both prepare_read and read/cancel always happen in the same thread?
08:50 kchibisov: I want prepare_read to fail if someone already called it on the same thread.
08:51 pq: yes, that's you goal 1, what about goal2?
08:51 kchibisov: And `cancel_read` to only decrement if current thread called `prepare_read`.
08:51 pq: oh, that sounds nasty
08:51 kchibisov: I want 1, 2 I just noticed.
08:52 kchibisov: since thread 1 calls prepare_read, but thread 2 for whatever reason called cancel_read, it'll mess up everything pretty much.
08:53 kchibisov: I think other issue is if you call `cancel_read`, but then `read_events`, it'll deadlock.
08:53 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.
08:54 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?
08:55 kchibisov: Ah, because of the dispatch_pending_loop....
08:55 kchibisov: since it implies that you try until you make it.
08:55 pq: All this should be in a libwayland issue, this is running out of IRC.
08:56 wlb: wayland.freedesktop.org Merge request !96 opened by Jonas Ådahl (jadahl) releases: Add wayland-protocols 1.42 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/96
08:56 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.
08:56 wlb: wayland.freedesktop.org Merge request !96 merged \o/ (releases: Add wayland-protocols 1.42 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/96)
08:56 wlb: wayland.freedesktop.org/main: Jonas Ådahl * releases: Add wayland-protocols 1.42 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/5aa134e36c26 releases.html
08:57 kchibisov: on _wayland_. if you do similar thing on x11 it just works iirc.
08:57 davidre: \o/
08:59 wlb: wayland-protocols/main: Simon Ser * color-management-v1: fix typo in feature.windows_scrgb https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/00a5b23bfef0 staging/color-management/color-management-v1.xml
08:59 wlb: wayland-protocols Merge request !386 merged \o/ (color-management-v1: fix typo in feature.windows_scrgb https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/386)
09:03 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.
09:04 kchibisov: the problem is when you have other thread doing blocking reads.
09:04 pq: why? They are their own threads, so how'd they deadlock?
09:05 pq: do you mean cross-thread synchronous calls?
09:05 kchibisov: if other thread will read and enqueue events for you, you won't know that in your external loop.
09:05 kchibisov: unless you call `wl_display_prepare_read` on the library's event_queue.
09:05 pq: Why is that a problem?
09:05 kchibisov: you'll just not wake-up when you have events, and you can block for a while due to that.
09:06 kchibisov: since you usually wait for READ readiness, but it got read by other thread, so you don't know that.
09:07 pq: right, and the prepare_read dance is a solution to that, but in this case it fails because..?
09:08 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.
09:08 kchibisov: on the same thread, I mean.
09:08 pq: but you just said "other thread"?
09:08 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.
09:10 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.
09:10 kchibisov: by the time I go from poll_events() back to `wait_for_event` clipboard could have enqueued events for winit's queue.
09:11 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.
09:11 kchibisov: To solve this, I'd need to call `prepare_read` right when I exit from `poll_events()` in winit.
09:12 kchibisov: But if my while(wait_for_event) loop had its own wayland stuff it could block.
09:12 pq: The blocking poll() syscall is part of the prepare_read dance, right? Done in both threads?
09:12 kchibisov: yeah.
09:12 kchibisov: The problem is external loop, that doesn't know about that semantic.
09:13 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.
09:13 pq: That's what event loop integration interfaces should be for.
09:13 kchibisov: yeah, and I could as a library say that `you must not do a blocking poll`.
09:14 pq: no, why?
09:14 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.
09:15 kchibisov: And even if I don't, the `epoll` waiting for readiness will be _sound_, since other thread won't be able to read.
09:15 pq: I have a very specific model of event loop integration interface in mind, I think Glib has it...
09:15 kchibisov: do you integrate into glib or you integrate glib into something?
09:15 kchibisov: There's no issue if integrate into the wayland loop, the problem when you put your wayland loop into some other loop.
09:16 pq: Shouldn't matter, I assume the interface is good in both directions when implemented by both components.
09:16 pq: https://docs.gtk.org/glib/main-loop.html#state-of-a-main-context
09:16 kchibisov: Yeah, I guess my issue is the convinience of how it's usually done.
09:17 pq: you could always add moar threads :-p
09:17 kchibisov: it's indeed an option.
09:19 kchibisov: it's just, if prepare_read failed if someone called it on the same thread, I think it'll just work.
09:19 kchibisov: Though, the existing assumption that you must re-try kind of breaks it a bit.
09:20 kchibisov: Though, if you have a destinct error code for `AlreadyCalled`, library can adjust to that.
09:21 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.
09:22 kchibisov: repeat iteration of calling to other external libs, etc, etc, since they are the ones calling `prepare_read`.
09:24 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.
09:24 kchibisov: Since it doesn't matter who will call read_events on the same thread.
09:24 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.
09:25 pq: I won't object, though, if others are happy.
09:26 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.
09:26 kchibisov: since you won't have a new error case.
09:26 kchibisov: and who calls the `read_events` doesn't really matter as long as it's on the same thread.
09:27 pq: It allows sloppy code though, where problem could be hidden deeper by adding more redundant calls.
09:27 kchibisov: I'll open for discussion at least.
09:27 pq: sure, this is just my personal opinion, and I'm not gatekeeping
09:28 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.
09:28 pq: if every lib did it the same way...
09:29 kchibisov: well, it's all nice when you can just put epoll into epoll.
09:29 kchibisov: but with wayland such trick doesn't really work.
09:30 pq: why does it work elsewhere? Is it because Wayland uses blocking readmsg() while others use non-blocking?
09:30 kchibisov: you usually don't share the same fd across multiple threads.
09:31 pq: maybe blocking readmsg() was the reason for the prepare_read thing in the first place.
09:31 pq: you don't?
09:31 pq: how do you achieve reading as needed?
09:32 kchibisov: I mean, you just have it dedicated to its own thread, having multiple readers from the same connection is not that common.
09:32 kchibisov: though, I could be wrong.
09:33 pq: and instead of the fd, you'd use condvars to wake up any thread waiting?
09:33 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.
09:33 wlb: weston Issue #1006 opened by Career Okay (careerokayofficials) Jobs in Karachi 2025: Comprehensive Guide to Career Opportunities https://gitlab.freedesktop.org/wayland/weston/-/issues/1006
09:33 kchibisov: you usually just read on the same thread, and disptach job to everyone else who needs it.
09:34 wlb: weston Issue #1006 closed \o/ (Jobs in Karachi 2025: Comprehensive Guide to Career Opportunities https://gitlab.freedesktop.org/wayland/weston/-/issues/1006)
09:34 kchibisov: in X11 world, we were just opening more connections.
09:35 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.
09:35 kchibisov: yeah, but you need to tell somehow to bind new stuff.
09:35 pq: What for?
09:36 kchibisov: Hm, true, you can do that yourself.
09:37 kchibisov: though, such interface must be supported by all libraries you're using, including mesa.
09:37 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().
09:38 kchibisov: the problem is that roundtrip is very common.
09:38 kchibisov: when you setup your lib to deal with registry, etc.
09:38 pq: roundtrip is a bug if called from any other context that the default wl_event_queue one.
09:39 pq: yeah, all components would need to cooperate
09:39 kchibisov: yeah, it's just I understand that it's possible, but reality is what we have.
09:40 pq: those that don't cooperate will need their guaranteed own thread I guess
09:40 pq: which also removes the need to integrate event loops
10:09 wlb: wayland Issue #531 opened by Kirill Chibisov (kchibisov) Integrating libwayland's event loop model into an external event loop https://gitlab.freedesktop.org/wayland/wayland/-/issues/531
13:15 wlb: weston Issue #1007 opened by Marius Vlad (mvlad) Separate Wayland socket for privileged clients as an alternative to filtering debug scopes https://gitlab.freedesktop.org/wayland/weston/-/issues/1007 [Debug]
13:37 wlb: weston Issue #994 closed \o/ (Weston gives multiple broken pipe errors in terminal emulators https://gitlab.freedesktop.org/wayland/weston/-/issues/994)
13:37 wlb: weston/main: Marius Vlad * terminal: Restore SIGPIPE signal handler to oldact (SIG_DFL) https://gitlab.freedesktop.org/wayland/weston/commit/f0ee8be8049b clients/terminal.c
13:37 wlb: weston Merge request !1695 merged \o/ (terminal: Restore SIGPIPE to default https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1695)
18:00 wlb: wayland-protocols Issue #251 opened by kentrl xiao (kentrl) Taskbar Icon Displacement/Duplication After System Upgrades on Wayland-based DEs https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/251
18:27 kennylevinsen: ...
18:28 vyivel: :)
18:32 llyyr: it doesn't matter if they're using LLM or not, this is just spam at this point
18:39 wlb: wayland-protocols Issue #251 closed \o/ (Taskbar Icon Displacement/Duplication After System Upgrades on Wayland-based DEs https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/251)