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