ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
jonesv has joined #wayland
<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.
<emersion>
jonesv: since the surface is invisible, the compositor might ignore the inhibitor…
ckinloch6 is now known as ckinloch
leon-anavi has quit [Quit: Leaving]
ckinloch is now known as Guest12973
<jonesv>
emersion: oh? Not always then, because it does work when I use it... or am I missing something?
<jonesv>
emersion: or does it depend on the compositor? I am using Sway, maybe Sway does not ignore it?
Guest12973 is now known as ckinloch
<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.
manuel has joined #wayland
<emersion>
sway doesn't check visibility at the moment, but that can be seen as a bug
manuel is now known as manuel1985
<jonesv>
kennylevinsen: right. I was just hoping that I could use it with an invisible surface :-)
<MrCooper>
the intention of the protocol is quite clearly that it shouldn't work
<kennylevinsen>
If that was supposed to work the protocol would not have required a surface argument :)
<jonesv>
Does that mean that it is impossible, with Wayland, to inhibit the idle mechanism from a command line?
<emersion>
in general Wayland is not designed for the command-line
<emersion>
for command-line apps, i mean
<kennylevinsen>
currently there is no general mechanism to disable idle without a visible surface
<jonesv>
:(
<kennylevinsen>
For sway and similar compositors, the idle behavior is implemented by an external tool (swayidle) and so there are ways to do it
<kennylevinsen>
E.g., stopping swayidle or replacing it with one doing what you'd want
<emersion>
sway also has IPC commands to manually toggle idle inhibitors
rgallaispou has left #wayland [#wayland]
<jonesv>
oh, sounds like the IPC command is what I want, then? And then my program is only working for sway
<kennylevinsen>
those also apply to specific windows, but I guess it could be set for the terminal window
<jonesv>
emersion: any keyword for this IPC command? Is that a dbus thing I should find in the docs?
<emersion>
no, swaymsg
tzimmermann has quit [Quit: Leaving]
<kennylevinsen>
man 5 sway, look for "inhibit"
<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`...
<jonesv>
Thanks a lot emersion kennylevinsen :-)
<jonesv>
emersion: is there a library to do that, or should I just `execvp swaymsg [...]` or something like that?
<emersion>
there are various sway/i3 IPC libraries for various languages
<emersion>
but a shell script would work fine as well
julio7359 has joined #wayland
<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?
<emersion>
something like this
<jonesv>
emersion: haha at least I learned some Wayland stuff doing it wrong :). Thanks again!
<emersion>
(and can be wrapped in a script to look like your original design)
<emersion>
np!
<emersion>
i think you may need to add a for_window in or something
<emersion>
but that's more of a #sway discussion now
<jonesv>
Got it. I'll do some tests and I'll go back to #sway :)
maxzor has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
kts has quit [Quit: Leaving]
maxzor has joined #wayland
nurupo has quit [Quit: nurupo.ga]
nurupo has joined #wayland
kenny has joined #wayland
sevz17 has joined #wayland
sevz has quit [Ping timeout: 480 seconds]
Guest12914 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest12994
Guest12994 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest12996
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
JoshuaAshton has quit [Quit: Gone froggin!]
mvlad has quit [Remote host closed the connection]
caveman has quit [Remote host closed the connection]
<Nefsen402>
xwayland is an xorg server that doubles as a wayland client
<immibis>
and what if Xorg implemented the Wayland protocol as well as X11?
<Nefsen402>
good luck finding someone who wants to fork x11 and start rummaging around in there to add support
<anarsoul>
immibis: Xorg would also have to incorporate some WM in this case
<Nefsen402>
s/x11/xorg
<immibis>
why would it? couldn't it just manage windows the way it already does?
<Nefsen402>
xorg only knows how to manage windows because of a compositor. The way it already does is by not doing it at all
<Nefsen402>
or in this case window manager
<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.
<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.
<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.
<emersion>
agreed
nerdopolis has quit [Ping timeout: 480 seconds]
rv1sr has quit []
<immibis>
the main benefit of wayland for most people will be the ability to run wayland apps
<psykose>
if that was the main benefit there would be no point to make it in the first place
<psykose>
then everyone could run every app
sevz has joined #wayland
sevz17 has quit [Ping timeout: 480 seconds]
<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.
<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.
<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
<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
<soreau>
except wayfire, it's little and has full xwayland compat :)
<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
<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)
<kennylevinsen>
vincejv: file that as a bug with KDE?
<vincejv>
open since Feb 2023
<immibis>
2024 is the year of the wayland desktop, so i'm sure they'll all switch over in 2024