00:00 kelnos: hey all, running into something unexpected. i have a xdg_toplevel and a wl_subsurface that uses that toplevel's wl_surface as its parent. i use wl_subsurface_place_below() to place the subsurface _below_ its parent, the xdg_toplevel. then when drawing the xdg_toplevel, i 'draw' a transparent area where the subsurface (below) is positioned. and then i draw on the subsurface the content i want to "peek through"
00:00 kelnos: however, on weston the area just shows black. on wayfire the area shows corrupted, like an uninitialized buffer
00:01 kelnos: is this something that should work?
00:05 soreau: kelnos: did you set the opaque region correctly?
00:06 soreau: because if you don't, weston assumes nothing can see 'through/behind' your surface, so it doesn't render anything behind it but clearing to black
00:09 soreau: same with wayfire
00:09 soreau: but it doesn't clear th fb, it just doesn't do anything
00:09 bluetail: interesting. wayland-proxy $(which thunar) seems to mitigate my issue.
00:10 soreau: bluetail: mitigate as in hasn't happened at all yet or happens less rarely?
00:11 bluetail: yea. The disconnect would happen immediately after I do the same things. Now I do that for 14 min and no exit
00:11 soreau: nice
00:11 soreau: is that mentioned on the MR for buffer size?
00:12 bluetail: sorry I haven't looked
00:12 bluetail: psykose posted link to wayland-proxy earlier
00:12 bluetail: do I need to report it on the MR?
00:14 bluetail: I mean, I probably do have the merged stuff, since I use wlroots-git, sway-git and so forth... right? So... does that mean the merged stuff is not enough?
00:16 psykose: which version of libwayland do you have
00:16 soreau:guess at least 1.23
00:17 bluetail: how do I find out?
00:17 psykose: which distro
00:17 bluetail: archlinux latest
00:17 soreau: pkg-config --modversion libwayland
00:17 soreau: libwayland-server*
00:17 psykose: 1.23.1 then
00:17 bluetail: https://0x0.st/X3cX.txt
00:18 bluetail: very confused
00:18 psykose: because the .pc files don't have lib in front
00:18 soreau: ah
00:19 soreau: it's yea
00:19 soreau: wayland-server*
00:19 psykose: in any case it's arch so 1.23.1
00:22 bluetail: yes. 1.23.1
00:22 bluetail: tab-autocomplete helped pkg-config --modversion wayland-server
00:52 kelnos: soreau ah i did not. let me try that...
00:53 soreau: kelnos: by default, if the opaque region is unset, the surface is assumed to be fully opaque
01:00 kelnos: soreau right. the thing i didn't mention is that gtk is involved, and i'm... abusing it... somewhat. and it turns out that gtk does set the opaque region for windows to the full area (most of the time, sometimes it doesn't, but in my case it was). so if i get it to stop doing that, then it does work. so thank you!
01:01 soreau: maybe just get the bits needed to make the call and then overwrite gtk's assumptions with what you want to happen
01:03 kelnos: a quick hack was to do gtk_widget_set_opacity(0.99) just to test if that was it (non-1.0 opacity causes it to clear out the surface's opaque region). but yeah, now i'm look at other places where it sets the opaqure region to see if i can override what it's doing
01:06 soreau: possibly just make the call in some signal that's emitted after it sets the opaque region
01:06 soreau: the compositor should get the hint
01:07 kelnos: unfortunately it doesn't fire off a signal every time it sets the opaque region. it does in gtk_window_realize(), but it also does "out of band" in GtkApplication, which doesn't appear to fire off any signals. but should be ok
01:08 soreau: check with WAYLAND_DEBUG=1 what's happening on the wire
01:08 kelnos: er, rather GtkApplicationWindow, not GtkApplication
01:09 kelnos: actually this is fine -- so i can connect to realize and size-allocate, and that should cover it
01:09 soreau: yea size allocate's a good one to hook in
01:09 soreau: I'd be interested to know if it works on wayfire
01:11 kelnos: yes, it's working on wayfire too
01:11 soreau: nice
01:12 kelnos: anyhow, thanks for your help!
01:14 soreau: No problem
08:11 bluetail: soreau it's been over 7 hours of extreme testing automated navigating. No exit!
08:20 MrCooper: zzag: right, that's what I suspected
08:31 linkmauve: kelnos, a much better way to do what you seem to want to do, is to use the GtkGraphicsOffload widget, see https://blog.gtk.org/2023/11/15/introducing-graphics-offload/
08:31 linkmauve: That way you don’t need to abuse anything, and GTK is still in full control of the layering of the subsurface.
08:35 zzag: MrCooper: yeah... how to implement it so it's not error prone is a whole different question, but I guess the xorg gitlab issue can be closed then
08:35 zzag: but...
08:35 zzag: I wonder whether this should be documented somewhere.. maybe in _XWAYLAND_ALLOW_COMMITS documentation, if there exists such?
08:36 MrCooper: makes sense
08:45 zzag: ofourdan: MrCooper: do you think that https://wayland.freedesktop.org/docs/html/ch05.html#sect-X11-Application-Support-xwm could contain such information?
08:45 zzag: we also need to update the window identification section to include a word or two about the xwayland-shell protocol
08:47 ofourdan: yes, I think this would be the right place - Xwayland itself has no dedicated documentation (also, this is meant for developers of Wayland compositors, not users)
08:48 ofourdan: that's a good idea
12:38 marton: is it okay to ask questions about wayland client development here?
12:39 davidre: yes just ask
12:39 marton: I'm trying to create a simple app that would highlight the mouse cursor and show mouse clicks (for screencasting and such), but can't figure out how to do it
12:40 marton: I've also asked this on stackoverflow here but got no response: https://stackoverflow.com/questions/78801124/how-can-i-receive-pointer-events-on-wayland-while-also-passing-them-through-to
12:40 marton: I've tried layer_surface and virtual pointers, but neither seem to work
12:41 marton: I also thought about reading mouse events directly from libinput and then just drawing the cursor using a layer_surface, but I don't like that either (it requires sudo, and also libinput only gives deltas, so the cursor position might go out of sync)
12:43 davidre: I think the answer is that as a wayland client you cant
12:44 davidre: Either your surface receives input or it doesnt
12:44 marton: hm, that's unfortunate
12:44 soreau: well..
12:44 marton: it's pretty common in GUI frameworks to receive events but also pass them through, no?
12:44 soreau: you could make a fullscreen/maximized transparent surface with empty input region and scribble on it..
12:45 soreau: but yea, most likely you'd want to find a compositor that has such a feature
12:45 davidre: empty input region means no input events though
12:45 marton: yep
12:45 soreau: yea was thinking that..
12:45 soreau: wayfire has a crosshair plugin but just renders.. crosshair for the mouse
12:46 soreau: I was thinking of writing some plugin like this for wayfire but I am wondering, how to nest represent visually which button was clicked
12:46 soreau: s/nest/best/
12:47 davidre: ⬅️ ⬆️ ➡️
12:47 davidre: Although that looks more like arrow keys
12:48 marton: I tried to hack around by having a full-screen input region plus a virtual pointer, and when I receive a mouse click, I turn off the input region and then use the virtual pointer to send the click
12:48 soreau: maybe a semi-transparent mouse image overlay and then highlight clicked buttons in red for $timeout
12:48 marton: that didn't work, but maybe I just didn't know how to properly sequence the events
12:49 soreau: marton: if clients could click on other clients, that'd probably be bad
12:50 marton: well it could also be very useful, automation, remote desktop control etc
12:50 marton: and I guess that's why the virtual pointer thing exists
12:50 soreau: wayfire and sway have ipc for this
12:51 soreau: so if you don't mind making it compositor-specific, there are ways..
12:51 marton: well I'm actually personally using sway, but I would like to make it general-purpose
12:52 soreau: doesn't virtual pointer only work on wlroots compositors?
12:53 soreau: (or any compositor that supports the wlr virtual pointer extension)
12:58 marton: while searching I also found this that gnome isn't planning to implement the layer-shell protocl: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1141
12:59 marton: there the suggestion was to "look at gamescope and mangohud - that's how it should be done" but those are big and complex cross-platform projects, so I couldn't figure out what they do
12:59 marton: yeah being limited to something like wlr / ones that implement some extension would be enough for me
12:59 marton: but I want it to work on more than just sway
13:07 soreau: marton: idk, maybe your hack could work if you flush requests after unsetting the input region and before calling virtual button
13:07 soreau: maybe some race-like condition
13:08 soreau: oh, it's double-buffered state, so probably requires a commit
13:10 soreau: "wl_surface.set_input_region changes the pending input region. wl_surface.commit copies the pending region to the current region. Otherwise the pending and current regions are never changed"
13:11 soreau: not sure if you need to wait for presentation feedback to make the button call or what
13:11 marton: I tried putting commits all over the place but couldn't get it to work
13:11 marton: but maybe I should try again
13:12 soreau: yes, try harder :)
13:12 soreau: sounds like it could work
13:12 marton: but it still feels dirty
13:13 soreau: but I'd try waiting for the feedback of the commit, so you know the compositor has ack'ed the state
13:13 marton: and I guess there can be a latency of some frames
13:21 soreau: and then what do you do for double+ clicks
13:22 marton: yeah that's also a problem, they can be too fast