05:04 <riteo> hi!

05:04 <riteo> kchibisov: btw the approach worked well enough!

05:05 <riteo> I've pretty much implemented what you proposed (along with Mailbox) but in the end we've scheduled a whole redraw instead of just buffer swapping for simplicity. There's a bit of inconsistency in frame times but stuff looks more than usable for a nice isolated, "compliant" workaround

05:05 <riteo> But now I'm getting issues with xdg_popup dismissal :(

05:08 <riteo> I'm a bit tired but I can't stop thinking about this. Apparently, when a popup gets hidden by the compositor (xdg_popup::popup_done) _while_ its surface gets "drawn" over (buffer attach, surface damage and all of that), the whole client crashes with errno 32

05:09 <riteo> I could replicate this with weston and sway, which isn't ecouraging. This seriously feels like a bug but it isn't https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2543 because I'm getting straight up a display error

05:11 <riteo> I have no idea how to continue... Do I (re?)report this? Do I give up on multiwindowing (which otherwise works) for now? Try on other compositors? This feels really bad considering the asynchronous nature of the protocol.

05:19 <riteo> uh right, sorry, the context is that I'm working on a Wayland port of the Godot game engine. Because godot is extremely main loop bound we also use a separate thread for even handling.

05:24 <riteo> *event

08:38 <riteo> oh well, I have to go. I'll keep an eye in the logs if anyone wants to tell me anything. Cya!

08:49 <kennylevinsen> riteo: (for the log) you need to share the Wayland debug log (WAYLAND_DEBUG=1), so the protocol violation can be diagnosed.

10:22 <MrCooper> zamundaaa: looks like simply logging into a KDE Plasma session creates/changes persistent dconf & GTK configuration such that later logging into GNOME results in KDE's cursor & icon themes being used; that's a bit... surprising, to put it diplomatically :)

15:14 <narodnik> greets

15:15 <narodnik> i'm trying to add wayland support to a library, and currently doing the keyboard input

15:15 <narodnik> i'm trying to make a minimal example: https://agorism.dev/uploads/main.c.txt

15:15 <narodnik> but when i run this it doesnt show any capabilities for the seat https://agorism.dev/uploads/output.txt

15:15 <narodnik> any ideas?

15:17 <kennylevinsen> narodnik: you are not servicing the display enough

15:17 <ifreund> narodnik: you won't get any events on the seat in the first roundtrip

15:17 <kennylevinsen> ^

15:17 <ifreund> if you add a second wl_display_roundtrip() your print should fire

15:19 <kennylevinsen> alternatively, loop on wl_display_dispatch to continously service the connection

16:07 <narodnik> aha tyvm

16:08 <narodnik> great that works!

16:29 <kchibisov> Hm, recently more compositors became angry when the buffer size / scale doesn't get divided. Which is a good practise, but what should we do with multiwindow clients and latching of EGL back buffers here? Clients have no clue whether the buffer is latched or not and they can latch the buffer just by making some other context current.

16:30 <kchibisov> While some latching is explicit, there're bugs with it, like eglMakeCurrent and eglCreateNewContext could do so.

16:34 <kchibisov> Maybe it should be relaxed for dma-buf clients?

19:20 <emersion> i'm not sure I'm following

19:21 <emersion> the commit happens iff swapbuffers is called

19:21 <emersion> that only can cause the protocol error

22:25 <Nosrep> what's the point of zwlr_data_control_device? it just looks like wl_data_whatever but without the drag and drop and with a primary selection

22:29 <kennylevinsen> Nosrep: https://wayland.app/protocols/wlr-data-control-unstable-v1 - see the top description. This protocol is for e.g. clipboard managers.

22:30 <Nosrep> what's stopping a clipboard manager from using wl_data_*? is it the primary selection part?

22:30 <Nosrep> i don't really use them so i wouldn't know

22:53 <danieldg> Nosrep: getting access to the clipboard while your window is *not* focused requires the privileged one

22:54 <Nosrep> i see

22:54 <danieldg> also a window manager might require a user action to be tied to a paste

22:56 <danieldg> (that's the purpose of the "serial" field in the accept action)

23:01 <Nosrep> ok, thanks