01:40eruditehermit: ofourdan: hello, are you around?
01:53eruditehermit: ofourdan: I have a new input-leap for you to test if you're interested and have time. I've tested it on many systems now and it should work so I'm wondering if your system is different in any way.
06:44ofourdan: hey, here now
06:44ofourdan: fwiw, the last one I tried for you last week was working fine
07:12eruditehermit: ofourdan: https://github.com/rohitpid/input-leap/actions/runs/10876241926 it's called input-leap-x864_64
07:13eruditehermit: ofourdan: it should have icons working and show in the system tray as well as show up in krunner or your launcher
07:13ofourdan: well, not using kde much over here :)
07:13ofourdan: but I can definitely try
07:14eruditehermit: ofourdan: hopefully those messages got sent
07:14ofourdan: yup,
07:14eruditehermit: I only saw but I can definitelyl try
07:14eruditehermit: if you sent a message before that
07:15ofourdan: see → https://oftc.irclog.whitequark.org/wayland/2024-09-16
07:15eruditehermit: beautiful, I didn't know the logger existed
07:15eruditehermit: it should show up in gnomes application thing too
07:16eruditehermit: basically the .desktop file is shipping now too
07:16ofourdan: gone dropped the system try long ago, you have to use an extension iirc
07:16ofourdan: *GNOME
07:17eruditehermit: hmm, I probably have the extension then
07:17eruditehermit: there are some apps that minimize to the tray and don't die, where do they go in gnome?
07:18ofourdan: ah, indeed, that's very possible, I suspects Ubuntu adds it to the default install
07:18eruditehermit: yeah that's probably it
07:18eruditehermit: distro specific installs
07:19eruditehermit: i could spin up some fedora/arch VMs
07:22eruditehermit: anyway, if you're interested in testing to see if your initial bugs/issues were fixed i'd be interested to know
07:22eruditehermit: you said it already worked last time?
07:22ofourdan: I'm installing it now, as we speak
07:34ofourdan: doesn't seem to work here, sorry
07:35eruditehermit: bummer
07:35eruditehermit: what's the distro and setup?
07:36eruditehermit: others have had success on fedora
07:37ofourdan: client and server do not seem to communicate, conenction from the client to theserver gets continuously refised - I tried diabling SSL (as I had issues with IL and SSL support when I was wormign on inplementing EI support) but that doesn't seem to help
07:37eruditehermit: ofourdan: what DE are you using?
07:38MrCooper: eluks: please fix your IRC setup
07:38ofourdan: I tried with GNOME and KDE, but as I said the issue is not with the desktop, it's the communication
07:38ofourdan: the client cannot conenct to the server
07:38eruditehermit: I know that portal has an issue with KDE 5.27
07:38ofourdan: it's not the portal :)
07:39ofourdan: brb
07:40eluks: MrCooper: thanks, will do so in some minutes. I seem to not be identified on my bouncer for the oftc network, even though i identified myself yesterday.
07:42MrCooper: FWIW, the main issue is that you keep disconnecting and reconnecting (while on channels)
07:47eluks: Can I assume the connection of the bouncer to the oftc network is instable, or can it also be the connection of my client (smartphone) to the bouncer?
07:51zzag: ofourdan: what's the usecase for the _XWAYLAND_ALLOW_COMMITS property? (I think I might have asked such a question in the past, I don't remember)
07:52ofourdan: it's used by the X11 window manager part of the Wayland compositor to tell Xwayland when to commit the wl_surface
07:53MrCooper: zzag: it allows the compositor to prevent Xwayland from attaching buffers, e.g. while resizing a window or during a _NET_WM_SYNC transaction
07:54zzag: MrCooper: can you please elaborate on the _NET_WM_SYNC part? what should a wayland compositor do?
07:55eruditehermit: ofourdan: on your client side, did you set it to autodetect or did you explicitly type in the IP address of the server? I have to type in the address of the server.
07:56MrCooper: zzag: when a _NET_WM_SYNC transaction starts, set _XWAYLAND_ALLOW_COMMITS such that Xwayland won't attach buffers to the surface, then when the transaction finishes clear it again
07:56ofourdan: compiling it with the NET_WM_SYNC part came after actually, the initial use case for allow commits as contributed by pq in 2016 initially for the first map, see https://gitlab.freedesktop.org/xorg/xserver/-/commit/9f4d308cda
07:57ofourdan: s/compiling/coupling/ (oops, muscle memory!)
07:57emersion: MrCooper: isn't this racy?
07:58zzag: MrCooper: I see.. Should the wayland compositor be concerned about buffer starvation? For example, the compositor starts a transaction/blocks commits -> clients renders a new frame and acks _NET_WM_SYNC -> the compositor unblocks commits -> ... -> a new transaction starts
07:58zzag: is it possible that no buffer will be attached in the "..." period?
07:58MrCooper: emersion: what exactly do you see racing with what?
07:59emersion: if the compositor is slow, Xwayland might still queue a new surface commit before the compositor has a chance to set _XWAYLAND_ALLOW_COMMITS?
07:59emersion: disclaimer, i have a very vague idea how _NET_WM_SYNC works
07:59MrCooper: zzag: not sure, IIRC Xwayland will attach a buffer immediately once the property is cleared, if there are new contents
08:00ofourdan: zzag: oh, you're asking in the context of https://gitlab.freedesktop.org/xorg/xserver/-/issues/1743, sorry I didn't realize at first!
08:00emersion: also would a compositor capable of blocking surface commits have no use for this prop?
08:01MrCooper: emersion: yes, but the attached buffer can only reflect contents from requests before _XWAYLAND_ALLOW_COMMITS was set, so should be fine
08:01zzag: MrCooper: "Xwayland will attach a buffer immediately once the property is cleared" okay
08:01MrCooper: emersion: without the property, there is a race as you describe
08:01zzag: ofourdan: yeah, I made https://invent.kde.org/plasma/kwin/-/commit/c36a6eda187af76ce880937c7eb2088d093f05e0. I don't see black strips anymore when resizing gedit, but the window contents still bounces (same thing with mutter)
08:02zzag: so I've been wondering about the _XWAYLAND_ALLOW_COMMITS approach
08:02ofourdan: oh kwin wasn't using allow commits at all before?
08:03zzag: yes, tbf we had been unaware of that property
08:05MrCooper: zzag: one potential issue with _XWAYLAND_ALLOW_COMMITS is that if the client uses PresentPixmap to update the window contents, that might not actually complete before _XWAYLAND_ALLOW_COMMITS is re-allowed
08:07zzag: MrCooper: hmm, I've been looking at xwayland source code and it appears like Xwayland doesn't commit the surface when the compositor changes the _XWAYLAND_ALLOW_COMMITS property? https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xwayland/xwayland-window.c?ref_type=heads#L152
08:07zzag: Am I missing something?
08:09zzag: There's
08:09zzag: ```
08:09zzag: xorg_list_add(&xwl_window->link_damage,
08:09zzag: &xwl_screen->damage_window_list);
08:09zzag: ```
08:09zzag: though
08:09MrCooper: right, xwl_window_set_allow_commits adds the xwl_window to xwl_screen->damage_window_list, so xwl_screen_post_damage will attach a new buffer for it
08:11zzag: MrCooper: okay... but that's going to work as expected only if the client renders **after** the compositor sets _XWAYLAND_ALLOW_COMMITS to true, isn't it?
08:12MrCooper: in theory it is possible for another _XWAYLAND_ALLOW_COMMITS change to prevent that, in practice I think it could only happen if both _XWAYLAND_ALLOW_COMMITS change requests are part of the same client display connection flush
08:12MrCooper: zzag: nope, it happens if there are any new contents since the last time a buffer was attached
08:13MrCooper: (any damage)
08:15zzag: MrCooper: ah... 🤦 I think I've missed the most important part. xwl_screen_post_damage() gets called every time Xwayland is about to return to spinning the event loop, right?
08:16zzag: xwl_screen_post_damage() gets called by block_handler() in xwayland-screen.c
08:16MrCooper: yep, exactly
08:16zzag: and the block_handler() is registered by RegisterBlockAndWakeupHandlers()
08:16zzag: okay, cool
10:07zzag: ofourdan: MrCooper: what are your thoughts about Xwayland synchronizing wl_surface::opaque_region with _NET_WM_OPAQUE_REGION? it would be sort of awkward to have Xwayland care about NetWM properties, but on the other hand, I'm not sure that the XSHAPE will gain opaque region as a native feature and for some wayland compositors supporting _NET_WM_OPAQUE_REGION creates architectural challenges
10:07zzag: as far as I know, wlroots-based compositors (cc emersion) and kwin would be interested in such a feature
10:07emersion: +1
10:07zzag: it would also help with _XWAYLAND_ALLOW_COMMITS being easier to handle
10:07zzag: because currently there are glitches caused by opaque region getting out of sync
10:08emersion: MrCooper: is there an upside to _XWAYLAND_ALLOW_COMMITS vs. deferring surface commits in the compositor?
10:08MrCooper: one problem with this is that mutter currently ignores wl_surface::opaque_region for Xwayland windows
10:08emersion: that should be fine no?
10:08emersion: mutter can continue to ignore if it has its own logic
10:09MrCooper: emersion: it avoids the race you described, and avoids Xwayland wasting effort on commits which will just be ignored
10:09emersion: right
10:09emersion: potentially copying stuff around
10:09emersion: or rendering
10:09zzag: MrCooper: it could continue using _NET_WM_OPAQUE_REGION. for example, Xwayland also sets the input region: mutter ignores it but kwin (and wlroots-based compositors too?) uses it
10:10MrCooper: k, then doing the same for the opaque region seems fair enough to me
10:11MrCooper: well, I guess _NET_WM_OPAQUE_REGION isn't quite the same thing as the input region though?
10:12MrCooper: the former is supposed to be between the client and WM, isn't it?
10:15emersion: or the X11 compositor?
10:15emersion: (since it's transparency-related)
10:25ofourdan: yes, X11 compositor
10:26ofourdan: (in many cases, the x11 window manager is also the compositor)
10:42MrCooper: the point being that the X server isn't supposed to do anything with it
11:18wlb: weston/main: Jan Alexander Steffens (heftig) * libweston/noop-renderer: Check shm_buffer for NULL https://gitlab.freedesktop.org/wayland/weston/commit/0e451e8dc38b libweston/noop-renderer.c
11:18wlb: weston Merge request !1614 merged \o/ (libweston/noop-renderer: Check shm_buffer for NULL https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1614)
11:51emersion: MrCooper: we've already bent the rules with NET_WM_PID
11:52emersion: and Xwayland is a bit of a special case since the X11 compositor ext isn't used for compositing
11:59ofourdan: emersion: Xwayland doesn't do anything with NET_WM_PID, I dropped my merge request
11:59emersion: oh
12:00emersion: out of curiosity, what was the reasoning?
12:00ofourdan: it is not needed
12:00emersion: "just use the X11 ext"?
12:01emersion: in any case, i don't think the ideology to keep X11 props handling out of the X11 server is worth it
12:01ofourdan: ah no, I didn't drop it, it's still there, https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/440 - But I think I should close it
12:02emersion: either we have a weird quirk in all Wayland compositors, either we have it in Xwayland
12:02ofourdan: yes, I would like to keep the window managerment logic in the window manager, and do not leak it in the Xserver.
12:02emersion: _NET_WM_OPAQUE_REGION is not really window management
12:03ofourdan: it's still a NET_WM_* property
12:03emersion: even if it has "WM" in its name - it's just the originating spec
12:03ofourdan: and there's a caveat there
12:04ofourdan: the opaque region applies to the window as shown on screen. Some Wayland compositors apply a different scaling to the Xwayland surface (kwin does that, mutter does that now with GNOME 47) and the coordinates of the region boxes need to be scaled, something alien to Xwayland in that case
12:05ofourdan: opaque region is a optimization for the compositor, I reckon it belongs to the compositor
12:05emersion: that should be fine no? all that comes from Xwayland needs to be scaled, opaque region included?
12:06zzag: ofourdan: the key thing here is that it's unlikely that XSHAPE is going to change to support opaque regions, but on the other hand, there are wayland compositors that struggle with supporting _NET_WM_OPAQUE_REGION because it doesn't fit the wl_surface abstractions
12:06ofourdan: well thta would break existing compoisitors which do that now, presumably
12:07zzag: ofourdan: we don't need the opaque region to be provided in _NET_WM_OPAQUE_REGION to support it
12:07zzag: to support scaling it*
12:07emersion: special-casing Xwayland in all compositors is just such a pain
12:07zzag: emersion: yes!!!
12:08emersion: it's like Xwayland scaling: we just don't support it in wlroots because it's a pain
12:08ofourdan: well, you have to provide an X11 window manager anyhow to support X11 and hence Xwayland
12:08emersion: but not an X11 compositor
12:08emersion: and that prop is read by the X11 compositor
12:09ofourdan: true
12:09emersion: i think the X11 server isn't even supposed to look at window props (but Xwayland does)
12:10ofourdan: the X11 server can do whatever it wants really :)
12:10ofourdan: it has access to all of that
12:10emersion: i mean in the ideal where it doesn't touch WM props etc
12:10ofourdan: right :)
12:16mclasen: there's plenty of prior art for X servers to read or set properties
12:28ofourdan: the problem is should the xserver do it. My point being, I wonder how existing Wayland compositors / X11 window managers, which alredy read and take the NET_WM_OPAQUE_REGION property into account would behave if the opaque region is also translated in Xwayland - IOW, I wonder if that might break existing compositors, especially those who do different scaling for Xwayland.
12:34zzag: ofourdan: as far as I know, there are two wayland compositors that read _NET_WM_OPAQUE_REGION: mutter and kwin. mutter ignores wl_surface::opaque-region. kwin won't be affected if xwayland sets the opaque region for Xwayland surfaces, the opaque region will be still scaled as expected (kwin has a notion of client global scale factor)
12:36ofourdan: "mutter ignores wl_surface::opaque-region" ← for Xwayland surfaces
12:36zzag: yeah
12:38ofourdan: also, the compositor won't update the content which is hidden behind an opaque region (that's the goal), if that comes from Wayland instead of X11, the event queues being separate, I wonder if that could induce some more visual glitches on resize. Worth a try I guess :)
12:40ofourdan: (or maybe I worry too much)
12:46ofourdan: but as you said, even if Xwayland does that translation, nothing stops a compositor to listen to the net_wm_opaque_region property and ignore the wl_surface opaque region for Xwayland surfaces, so eventualyl, that remains a compositor choice.
12:47zzag: yeah, exactly
13:18wlb: weston Merge request !1615 opened by () libweston/screenshooter: Fix build when __builtin_clz is not available https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1615
15:29kts: The world as I/O.
15:40wlb: wayland Merge request !429 opened by () Add a thread ID to WAYLAND_DEBUG output. https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/429
19:10zzag: MrCooper: ofourdan: I figured out what causes bouncing.. kwin (and I guess mutter?) does the following currently: send a sync request, block wl_surface commits, and configure the window(s) -> (a few moments later) -> the clients repaints the window and acks the sync request -> the compositor sees that the sync request has been acked so it updates its private state associated with the window (e.g. update the geometry) and unblocks
19:10zzag: wl_surface commits -> (N milliseconds later) -> the compositor paints a new frame -> (N milliseconds later) -> Xwayland commits a new buffer
19:11zzag: if I make kwin wait until Xwayland commits something to update the window geometry, it appears there are no issues when resizing gedit now
19:12zzag: there are still issues when resizing chromium, but I suspect that it may not support NET_WM_SYNC properly
19:17vyivel: does any browser support frame perfect resizing at all
19:17zzag: heh indeed :D
22:31bluetail: I noticed some applications like thunar report "disconnected from wayland compositor". Is that a known issue under wayland? It happened just by searching through huge folders.
22:32bluetail: I noticed other applications do the same thing when theres enough load - or simply a slow disk involved for instance from sshfs
22:32bluetail: but it's not always the case
22:33bluetail: with thunar at least I can reproduce, but I didn't see anything interesting in WAYLAND_DEBUG and there was no coredump. Therefore probably no crash.
22:43soreau: have you tried with more than one compositor? could be something the server is doing (wrong)
22:46psykose: sounds like older libwayland and the socket gets filled up as the client doesn't read it in the middle of a blocking operation (iterating through a lot of files in thunar) so if you move your mouse the server kills the client for being unresponsive
22:53linkmauve: bluetail, the proper way to fix that is to run the blocking operations on a different thread from the UI.
22:53bluetail: soreau psykose I am on sway with latest wlroots and dev versions of said programs
22:53linkmauve: So that the UI can be responsive at all times.
22:53bluetail: I think thats the right guess linkmauve
23:10llyyr: applications like firefox put a proxy to avoid being disconnected by the compositor, and if I understand the problem right, https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188 should help with that
23:12bluetail: thanks
23:16psykose: does firefox do proxying itself? i only saw third party projects do that
23:17psykose: like https://github.com/stransky/wayland-proxy
23:17psykose: ah, it was merged into firefox proper apparently
23:17psykose: neat
23:22llyyr: It does so since 123, thunderbird also desperately needs it to not get killed by the compositor if you try to delete a thread of emails
23:25psykose: did they not enable it with 128 esr
23:29llyyr: donno
23:33bluetail: intriguing