01:29 wlb: weston Merge request !1437 opened by JeffyChen (JeffyCN) desktop-shell: Use real size for non-image background https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1437
01:43 wlb: wayland Merge request !359 opened by Thomas Lukaszewicz (tluk) Draft: Mitigate UAF crashes due to wl_client_destroy reentrancy https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/359
02:12 wlb: weston Merge request !1437 closed (desktop-shell: Use real size for non-image background)
08:34 wlb: weston/main: Jeffy Chen * libweston: Avoid double-destroy of animations https://gitlab.freedesktop.org/wayland/weston/commit/b0741868368a libweston/animation.c
08:34 wlb: weston Merge request !1434 merged \o/ (libweston: Avoid double-destroy of animations https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1434)
16:09 jonesv: I wrote a very small executable that runs a `zwp_idle_inhibitor_v1` while another command is running, such that I can run `./inhibit-idle make` and I know that Wayland won't trigger the idle actions during my compilation.
16:09 jonesv: It is the very first time I use Wayland, is there any chance I could get a quick review on how I approached it? https://git.sr.ht/~jonasvautherin/inhibit-idle/tree/master/item/inhibit-idle.c
16:09 jonesv: Also is this the right place to ask? :-)
16:16 emersion: jonesv: since the surface is invisible, the compositor might ignore the inhibitor…
16:23 jonesv: emersion: oh? Not always then, because it does work when I use it... or am I missing something?
16:24 jonesv: emersion: or does it depend on the compositor? I am using Sway, maybe Sway does not ignore it?
16:31 kennylevinsen: jonesv: the purpose of an idle inhibitor is to say "my surface is presenting something the user would not want interrupted by idle". As en example, a video player would use it and the compositor would then inhibit idle when that video player is visible.
16:34 emersion: sway doesn't check visibility at the moment, but that can be seen as a bug
16:39 jonesv: kennylevinsen: right. I was just hoping that I could use it with an invisible surface :-)
16:39 MrCooper: the intention of the protocol is quite clearly that it shouldn't work
16:40 kennylevinsen: If that was supposed to work the protocol would not have required a surface argument :)
16:40 jonesv: Does that mean that it is impossible, with Wayland, to inhibit the idle mechanism from a command line?
16:41 emersion: in general Wayland is not designed for the command-line
16:41 emersion: for command-line apps, i mean
16:42 kennylevinsen: currently there is no general mechanism to disable idle without a visible surface
16:42 jonesv: :(
16:42 kennylevinsen: For sway and similar compositors, the idle behavior is implemented by an external tool (swayidle) and so there are ways to do it
16:43 kennylevinsen: E.g., stopping swayidle or replacing it with one doing what you'd want
16:43 emersion: sway also has IPC commands to manually toggle idle inhibitors
16:44 jonesv: oh, sounds like the IPC command is what I want, then? And then my program is only working for sway
16:44 kennylevinsen: those also apply to specific windows, but I guess it could be set for the terminal window
16:45 jonesv: emersion: any keyword for this IPC command? Is that a dbus thing I should find in the docs?
16:45 emersion: no, swaymsg
16:45 kennylevinsen: man 5 sway, look for "inhibit"
16:52 jonesv: oh, looks like I may want `swaymsg inhibit_idle open`, and it will inhibit while the terminal window is open. Assuming this works when run with `execvp`...
16:53 jonesv: Thanks a lot emersion kennylevinsen :-)
17:02 jonesv: emersion: is there a library to do that, or should I just `execvp swaymsg [...]` or something like that?
17:03 emersion: there are various sway/i3 IPC libraries for various languages
17:03 emersion: but a shell script would work fine as well
17:08 jonesv: emersion: oh I can just run `swaymsg inhibit_idle open && make; swaymsg inhibit_idle none` and it should do the job. Is that what you mean?
17:08 emersion: something like this
17:09 jonesv: emersion: haha at least I learned some Wayland stuff doing it wrong :). Thanks again!
17:09 emersion: (and can be wrapped in a script to look like your original design)
17:09 emersion: np!
17:10 emersion: i think you may need to add a for_window in or something
17:11 emersion: but that's more of a #sway discussion now
17:11 jonesv: Got it. I'll do some tests and I'll go back to #sway :)
21:38 immibis: what if xorg was a wayland compositor?
21:50 Ermine: wdym?
21:51 Ermine: Xorg implements X11 protocol, wayland compositors implement wayland protocol
21:51 Nefsen402: xwayland is an xorg server that doubles as a wayland client
21:53 immibis: and what if Xorg implemented the Wayland protocol as well as X11?
21:54 Nefsen402: good luck finding someone who wants to fork x11 and start rummaging around in there to add support
21:56 anarsoul: immibis: Xorg would also have to incorporate some WM in this case
21:56 Nefsen402: s/x11/xorg
21:56 immibis: why would it? couldn't it just manage windows the way it already does?
21:57 Nefsen402: xorg only knows how to manage windows because of a compositor. The way it already does is by not doing it at all
21:57 Nefsen402: or in this case window manager
22:03 kennylevinsen: immibis: you could write a new display server that natively supported Wayland and X11, but I don't think anyone wants to do that. Instead, xorg was modified to speak Wayland as compat layer.
22:06 kennylevinsen: You could also do the opposite of Xwayland if you wanted (waylandX?), but I don't think adding Wayland *server* support to Xorg makes *any* amount of sense - even if you could theoretically make it work with X11's split server/compositor/wm design.
22:09 kennylevinsen: You wouldn't really get any of the benefits of Wayland if you tried to teach it directly to Xorg, so it wouldn't be better than a theoretical waylandX compat layer.
22:10 emersion: agreed
22:35 immibis: the main benefit of wayland for most people will be the ability to run wayland apps
22:37 psykose: if that was the main benefit there would be no point to make it in the first place
22:37 psykose: then everyone could run every app
22:47 ids1024: Yeah. I think if you want Wayland clients on X, a "WaylandX" (opposite of XWayland) conversion layer is definitely the most practical choice. Shouldn't be that hard, really, should be much easier than adding Wayland support directly to Xorg, and should basically work and perform the same anyway.
22:48 ids1024: If you want to continue using X for too much longer, you'll want something like that. When toolkits and apps start dropping X support.
22:49 soreau: I have hacked weston to do this once upon a time, and it is quite the pointless exercise for all the reasons mentioned above
22:50 soreau: https://github.com/soreau/weston/commit/c62d20867d87ae0d7af89c650290dbcf6930bdc6
22:55 immibis: 2024 will be the year of the wayland desktop
23:06 kennylevinsen: immibis: if you want to run Wayland apps (which most apps support now), any of the big Wayland servers will do that best and have full X11 compatibility
23:09 soreau: except wayfire, it's little and has full xwayland compat :)
23:10 vincejv: immibis: got some flickering issues with latest stable KDE wayland atm, jellyfin mpv shim doesn't fully support wayland, i hope the fixes are coming in 2024
23:10 kennylevinsen: (For those really insisting on running xorg, there isn't a really a lot of Wayland-only clients to worry about in the first place - likely why no one bothered with a WaylandX yet)
23:10 kennylevinsen: vincejv: file that as a bug with KDE?
23:11 vincejv: open since Feb 2023
23:13 immibis: 2024 is the year of the wayland desktop, so i'm sure they'll all switch over in 2024
23:14 Sachiel: the trolling game is weak on this one
23:41 kennylevinsen: indeed