07:33 kennylevinsen: danieldg: only tiling compositors need to synchronize toplevels, and even then it's just a wait until ack_configure. Writing a client with subsurfaces, in particular desync and externally controlled ones, correctly so that the toplevel doesn't appear glitchy is another problem altogether...
07:36 narodnik: hey is there a simple code sample showing how to copy/paste from the clipboard?
07:42 narodnik: i tried looking at wl-clipboard but it's so complicated https://github.com/bugaevc/wl-clipboard/tree/master/src/types
07:52 pq: narodnik, I would say that clipboard handling at the Wayland protocol level of asbtraction is fundamentally complicated.
07:53 kode54: narodnik: the copying app *is* the clipboard
07:53 pq: you'll also need a visible window in the same client
07:53 kode54: wl-copy lives for the life of the copy
07:54 pq: you'll be able to copy/paste when your visible window gets input events that you can refer to
07:59 pq: narodnik, the transport is writing/reading a pipe, and the mime-type negotiation is needed to agree on the data format first. Is that what you referred to as complicated?
08:00 pq: writing/reading a pipe without freezing the app is its own chore
08:08 narodnik: i have a visible window, and a wayland client
08:09 narodnik: and the seat .etc, but then i want to just copy/paste text from the clipboard
08:09 narodnik: the mime type is just simply text
08:10 narodnik: was wondering if there's a short code sample rather than having to reverse engineer wl-clipboard
08:18 pq: it's not a short code
08:19 pq: you'll have to deal with the pipe
08:21 pq: Weston's clients/window.c has some self-standing code, too, but I'm looking if there is an obvious entry point you could start to untangle it from...
08:22 kennylevinsen: narodnik: bind the wl_data_device_manager, get the wl_data_device, accept the incoming wl_data_offer's appropriate mime type, and send an fd over receive to have the data written to, then destroy the offer
08:23 kennylevinsen: But handling the pipe to be used as fd takes a bit of code
08:23 kennylevinsen: To not risk blocking the whole client for an indeterminate amount of time
08:26 narodnik: thanks a lot, appreciate the help + any further advice
08:28 pq: clients/window.c display_add_data_device() binds the data device manager, so that's a starting point.
08:30 narodnik: ty, appreciated
08:32 pq: input_set_selection() seem to be the "copy/cut" function
08:48 narodnik: gotcha thanks
14:13 pq: Funny how P3D65 is supposed to have peak encoded luminance of 48 cd/m². Maybe it's a different P3D65 from Apple's...
14:19 pq: also funny that P3 implies power-law TF exponent 2.6
19:20 thalos: Hi! Maybe a stupid question but, I just switched to wayland (running hyprland as compositor), I can't seem to find any log file or status, like Xorg.log in order to see how wayland has detected my hardware. Am I missing something?
19:20 bl4ckb0ne: that's a hyprland question, compositors manage their own logs
19:21 bl4ckb0ne: wayland has nothing to do with it, it's just an protocol
19:21 thalos: I see, thanks
19:27 emersion: narodnik: maybe this could help https://emersion.fr/blog/2020/wayland-clipboard-drag-and-drop/
19:43 JoshuaAshton: emersion: Interesting article. I should hook up copy paste for the Wayland subsurface backend in Gamescope at some point