ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<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"
<kelnos> however, on weston the area just shows black. on wayfire the area shows corrupted, like an uninitialized buffer
<kelnos> is this something that should work?
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
<soreau> kelnos: did you set the opaque region correctly?
<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
<soreau> same with wayfire
<soreau> but it doesn't clear th fb, it just doesn't do anything
<bluetail> interesting. wayland-proxy $(which thunar) seems to mitigate my issue.
<soreau> bluetail: mitigate as in hasn't happened at all yet or happens less rarely?
<bluetail> yea. The disconnect would happen immediately after I do the same things. Now I do that for 14 min and no exit
<soreau> nice
<soreau> is that mentioned on the MR for buffer size?
<bluetail> sorry I haven't looked
<bluetail> psykose posted link to wayland-proxy earlier
<bluetail> do I need to report it on the MR?
<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?
<psykose> which version of libwayland do you have
* soreau guess at least 1.23
<bluetail> how do I find out?
<psykose> which distro
<bluetail> archlinux latest
<soreau> pkg-config --modversion libwayland
<soreau> libwayland-server*
<psykose> 1.23.1 then
<bluetail> very confused
<psykose> because the .pc files don't have lib in front
<soreau> ah
<soreau> it's yea
<soreau> wayland-server*
<psykose> in any case it's arch so 1.23.1
<bluetail> yes. 1.23.1
<bluetail> tab-autocomplete helped pkg-config --modversion wayland-server
<kelnos> soreau ah i did not. let me try that...
<soreau> kelnos: by default, if the opaque region is unset, the surface is assumed to be fully opaque
<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!
<soreau> maybe just get the bits needed to make the call and then overwrite gtk's assumptions with what you want to happen
<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
<soreau> possibly just make the call in some signal that's emitted after it sets the opaque region
<soreau> the compositor should get the hint
<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
<soreau> check with WAYLAND_DEBUG=1 what's happening on the wire
<kelnos> er, rather GtkApplicationWindow, not GtkApplication
<kelnos> actually this is fine -- so i can connect to realize and size-allocate, and that should cover it
<soreau> yea size allocate's a good one to hook in
<soreau> I'd be interested to know if it works on wayfire
<kelnos> yes, it's working on wayfire too
<soreau> nice
<kelnos> anyhow, thanks for your help!
<soreau> No problem
fmuellner_ has quit []
eruditehermit has joined #wayland
eruditehermit has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
mxz__ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz_ has quit [Ping timeout: 480 seconds]
mxz__ is now known as mxz
mxz_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
eruditehermit has joined #wayland
rockzx has quit [Remote host closed the connection]
alatiera has quit [Ping timeout: 480 seconds]
eruditehermit has quit [Ping timeout: 480 seconds]
eruditehermit has joined #wayland
glennk has joined #wayland
mclasen has joined #wayland
meltq has joined #wayland
rockzx has joined #wayland
rockzx has quit [Remote host closed the connection]
meltq has quit [Ping timeout: 480 seconds]
rockzx has joined #wayland
rasterman has joined #wayland
rv1sr has joined #wayland
coldfeet has joined #wayland
kts has joined #wayland
JakeSays1 has joined #wayland
kts has quit [Quit: Leaving]
eruditehermit has quit [Ping timeout: 480 seconds]
JakeSays has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
kts has joined #wayland
mclasen has joined #wayland
leon-anavi has joined #wayland
mclasen has quit [Remote host closed the connection]
mclasen has joined #wayland
mclasen has quit [Quit: mclasen]
MrCooper has joined #wayland
<bluetail> soreau it's been over 7 hours of extreme testing automated navigating. No exit!
<MrCooper> zzag: right, that's what I suspected
eruditehermit has joined #wayland
<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/
leon-anavi has quit [Remote host closed the connection]
<linkmauve> That way you don’t need to abuse anything, and GTK is still in full control of the layering of the subsurface.
<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
<zzag> but...
<zzag> I wonder whether this should be documented somewhere.. maybe in _XWAYLAND_ALLOW_COMMITS documentation, if there exists such?
<MrCooper> makes sense
<zzag> ofourdan: MrCooper: do you think that https://wayland.freedesktop.org/docs/html/ch05.html#sect-X11-Application-Support-xwm could contain such information?
<zzag> we also need to update the window identification section to include a word or two about the xwayland-shell protocol
<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)
<ofourdan> that's a good idea
eruditehermit has quit [Quit: Konversation terminated!]
kts has quit [Quit: Leaving]
sima has joined #wayland
kts has joined #wayland
latex has joined #wayland
latex_ has quit [Ping timeout: 480 seconds]
Company has joined #wayland
eruditehermit has joined #wayland
kts has quit [Quit: Leaving]
alatiera has joined #wayland
eruditehermit has quit [Ping timeout: 480 seconds]
lockywolf has quit [Remote host closed the connection]
lockywolf has joined #wayland
nerdopolis has joined #wayland
fmuellner has joined #wayland
noord has quit [Quit: bye]
noord has joined #wayland
marton has joined #wayland
<marton> is it okay to ask questions about wayland client development here?
davidre has joined #wayland
<davidre> yes just ask
<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
<marton> I've tried layer_surface and virtual pointers, but neither seem to work
<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)
<davidre> I think the answer is that as a wayland client you cant
<davidre> Either your surface receives input or it doesnt
<marton> hm, that's unfortunate
<soreau> well..
<marton> it's pretty common in GUI frameworks to receive events but also pass them through, no?
<soreau> you could make a fullscreen/maximized transparent surface with empty input region and scribble on it..
<soreau> but yea, most likely you'd want to find a compositor that has such a feature
<davidre> empty input region means no input events though
<marton> yep
<soreau> yea was thinking that..
<soreau> wayfire has a crosshair plugin but just renders.. crosshair for the mouse
<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
<soreau> s/nest/best/
<davidre> ⬅️ ⬆️ ➡️
<davidre> Although that looks more like arrow keys
<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
<soreau> maybe a semi-transparent mouse image overlay and then highlight clicked buttons in red for $timeout
<marton> that didn't work, but maybe I just didn't know how to properly sequence the events
<soreau> marton: if clients could click on other clients, that'd probably be bad
<marton> well it could also be very useful, automation, remote desktop control etc
<marton> and I guess that's why the virtual pointer thing exists
<soreau> wayfire and sway have ipc for this
<soreau> so if you don't mind making it compositor-specific, there are ways..
<marton> well I'm actually personally using sway, but I would like to make it general-purpose
<soreau> doesn't virtual pointer only work on wlroots compositors?
<soreau> (or any compositor that supports the wlr virtual pointer extension)
<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
<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
<marton> yeah being limited to something like wlr / ones that implement some extension would be enough for me
<marton> but I want it to work on more than just sway
<soreau> marton: idk, maybe your hack could work if you flush requests after unsetting the input region and before calling virtual button
<soreau> maybe some race-like condition
<soreau> oh, it's double-buffered state, so probably requires a commit
<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"
<soreau> not sure if you need to wait for presentation feedback to make the button call or what
<marton> I tried putting commits all over the place but couldn't get it to work
<marton> but maybe I should try again
<soreau> yes, try harder :)
<soreau> sounds like it could work
<marton> but it still feels dirty
<soreau> but I'd try waiting for the feedback of the commit, so you know the compositor has ack'ed the state
<marton> and I guess there can be a latency of some frames
___nick___ has quit [Ping timeout: 480 seconds]
<soreau> and then what do you do for double+ clicks
<marton> yeah that's also a problem, they can be too fast
Moprius has joined #wayland
feaneron has joined #wayland
Moprius has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
kts has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
aswar002 has quit [Remote host closed the connection]
shankaru has quit [Read error: Connection reset by peer]
aswar002 has joined #wayland
shankaru has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
plouton has quit []
___nick___ has joined #wayland
mohit81582263530 has quit [Quit: mohit81582263530]
mohit81582263530 has joined #wayland
rasterman has joined #wayland
kts has quit [Quit: Leaving]
riteo has joined #wayland
___nick___ has quit [Remote host closed the connection]
___nick___ has joined #wayland
coldfeet has quit [Remote host closed the connection]
Lucretia has quit [Ping timeout: 480 seconds]
eruditehermit has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
plouton has joined #wayland
Lucretia has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
Calandracas has joined #wayland
Calandracas_ has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
eruditehermit has quit [Ping timeout: 480 seconds]
___nick___ has quit [Remote host closed the connection]
fmuellner_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
rv1sr has quit []
eruditehermit has joined #wayland
bjorkintosh has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
sima has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
Brainium has joined #wayland
bjorkintosh has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
CME_ has joined #wayland
CME has quit [Read error: Connection reset by peer]
plouton has quit []
rasterman has joined #wayland
Lucretia has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]