05:16 <elwolf> im having issues with wayland and a dual monitor setup

05:16 <elwolf> my 2nd monitor is to the left of my main one

05:16 <elwolf> with "output DP-3 pos 0 0" and "output HDMI-A-1 pos 1920 0" it acts as if my 2nd monitor is to the right of my main

05:17 <elwolf> but no matter how i mix and match these numbers it wont work how i want it to

06:48 <emersion> elwolf: hi, if you're using sway, please ask questions about sway in the #sway channel on libera chat

08:25 <pq> swick, could you leave a comment in e.g. https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582 with the copyright line you want?

08:25 <gitlab-bot> wayland issue (Merge request) 582 in weston "Color management architecture: color transformations and a plugin" [Colour Management, Core Compositor, Opened]

09:08 <hesperos66> how do you guys usually handle external IPCs within compositors and maintain thread safety? I need to implement handling requests like focus view or marking views as dirty (from outside) by `weston_view_geometry_dirty` but it seems that in order to do that I'd have to have a pipe, create messaging system and within the message handler deserialise my custom payloads to eventually execute things like

09:08 <hesperos66> `weston_view_geometry_dirty` - this seems like an awful amount of work and a problem that I imagine may have been already solved?

09:13 <daniels> it hasn't really been solved, because you already have a synchronisation issue

09:13 <daniels> e.g. if the client disconnects in the main thread, the weston_view pointer you have in your other thread may be invalid

09:13 <daniels> so you'd need to add some kind of lifetime management (so you didn't have a race against destruction), as well as parallel management (so you didn't have a race against concurrent updates)

09:14 <daniels> this is the case for basically all compositors

09:24 <hesperos66> daniels: I do have an object lifetime management in place. In case of i.e. views, these are easily managable as you can create them as needed as a result of i.e. surfaceAdded callbacks with something like `weston_desktop_surface_create_view` - similarly with destruction on surfaceRemoved callbacks - that guarantees that all these operations will happen on the same thread as the one that event loop

09:24 <hesperos66> uses. Not sure though how to handle "external" requests. I've got a DBus API that my compositor exposes that allows to focus/unfocus arbitrary client - not sure though how to make it thread safe as, as I explained, it seems that I'd have to do this message serialisation/deserialisation and posting via pipe to event loop to eventually call the "real" weston APIs to perform the action

09:25 <hesperos66> looking at sway's IPC - it seems to be doing exactly that. I was hoping that this problem may have already been solved in i.e. wlroots?

09:30 <emersion> i'd really recommend against doing multi-threading

09:31 <emersion> we're doing it in gamescope and it's such a pain

09:31 <emersion> no, wlroots doesn't deal with multi-threading synchronization issues

09:32 <emersion> and sway is single-threaded, and that's considered to be a feature, not a bug :P

09:33 <daniels> hesperos66: it sounds like you don't actually need threads at all ... ?

09:33 <daniels> hesperos66: I mean, the point is, when the client disconnects, the weston_view* will be destroyed and become invalid

09:34 <daniels> this can happen as your other thread is processing a message to focus that view, at which point you'll access invalid memory and crash, because there is no locking or synchronisation between the two threads

09:34 <daniels> but you don't need a thread to dispatch dbus events, you can integrate it as a wl_event_source

09:34 <daniels> this is exactly what sway does for its external IPC as well

09:35 <daniels> get the FD for the DBusConnection and add that as an event source, then do a non-blocking dispatch of D-Bus events when that FD becomes ready

09:42 <daniels> (and then you can handle your D-Bus events in the main thread, and your synchronisation issues magically vanish)

09:44 <pq> hesperos66, no, your thing with views guarantees nothing.

09:45 <pq> hesperos66, when a Wayland client disconnects, it will destroy the weston_surface, which will destroy *all* views of that surface *in the main thread*.

09:46 <pq> hesperos66, trying to make libweston usable from multiple threads is not feasible.

09:48 <daniels> (same with wlroots or any other framework)

09:49 <pq> I just hope hesperos66 does not need to use any third party API that is inherently blocking.

15:59 <ekurzinger> Hello, is anyone aware of any Vulkan applications that can use the native Wayland WSI? The only thing I've been able to find is Khronos's vkcube.

16:02 <emersion> anything using glfw or SDL should work too (iirc for SDL needs an env var)

18:06 <jadahl> ekurzinger: gtk4 has a vulkan renderer that might or might not work