<dramforever[m]1>
hiya: i think i misread, "what would still make legacy X11 apps to function" *is* xwayland
<hiya>
dramforever[m]1: I think I need to understand this more, I am even more confused about the role of wayback now
<dramforever[m]1>
you can run x11 window managers without wayback
<dramforever[m]1>
If you have a wayland compositor, try this out: Xwayland -hidpi :3 & WAYLAND_DISPLAY= DISPLAY=:3 i3
<dramforever[m]1>
but this is now how you normally start an X server
<dramforever[m]1>
the role of wayback is to make this work the normal way you would start an X server, be it startx, or some display manager, or whatever...
<dramforever[m]1>
dramforever[m]1: i meant "not how"
<hiya>
Okay
anabelae[m] has joined #wayback
<anabelae[m]>
You get to your login manager, select your favorite xwm and it will be started, even without having the xserver binary, which communicates with the underlying hardware, installed on the system. Instead of launching it with startx, it will run as a root Xwayland window started from wayback. That means Wayland is the one communicating with hw through translating x11 calls from xwayland
<f_>
hiya: the goal of Xwayback is to replace Xorg while letting you run your favourite X11 WMs. It is essentially a glue for Xwayland but it will be much more than that later on.
<f_>
Technically it using Wayland internally is irrelevant to the user, because it's an implementation detail (also you can't run other wayland apps with it)
<f_>
But it should make maintaining support for X11 WMs alongside Wayland much easier
<f_>
for distro maintainers that is.
<f_>
Also compared to Xlibre we are interested in building sustainable solutions, not arguing about DEI and spreading hartred on mailing lists :P
tgirl has quit [Ping timeout: 276 seconds]
<hiya>
so, when all of the code of xorg is purged - people could just use wayback, if and when required?
<f_>
yep
<hiya>
would it eventually do something about xwayland or it would always be required?
<hiya>
or there is no comments on this for now, as to what the future of this project holds
<f_>
Xwayland is still actively maintained, so no
<hiya>
I see.
<hiya>
Thank you so much for the kind information.
tgirl has joined #wayback
jvvv has joined #wayback
<f_>
hiya: you're welcome!
<f_>
Should we do 0.1.1 now?
<f_>
that just includes d1642f03ee62ff3b42caf29e1ef6f233e4d12a86 ?
<f_>
and no this is not the irssi script this is irssi itself or the double-tmux I have mangling
<f_>
whatever
mojo_ has joined #wayback
vimpostor has joined #wayback
<f_>
Oh by the way, maybe let's show the wayback version in -version ?
<bigmac>
When executed with Xwayback, should it merge Xwayland output and Xwayback version output in a way? -version is a valid Xwayland flag and someone might want to check the version of Xwayland through Xwayback I can imagine
<bigmac>
Well the expected behaviour is to be able to pass flags to Xwayland. So when one passes the -version flag they might expect Xwayland's version
<f_>
^ maybe let's get this in too for 0.1.1? It's a minor thing
<f_>
bigmac: hmm we don't pass *all* flags to Xwayland, only those that are unknown to Xwayback
<f_>
and that aren't explicitely blacklisted
<axtlos>
I don't think it's a common use to request the xwayland version through wayback
<axtlos>
it's not like xwayland is exclusively a library, users can execute xwayland to get the version
<bigmac>
f_: I am I reading it wrong that everything from argv gets passed over to the xwayland posix spawn?
<f_>
nope, not everything gets passed over
<f_>
all Xorg-specific options not handled by Xwayland are blacklisted
<mccd>
Heya, currently all Xwayland apps look blurry to me. Will this still be the case with wayback? Also congrats on the preview release :)
<f_>
mccd: DPI?
<dramforever[m]1>
mccd: xwayland being blurry is a compositor-specific thing
<dramforever[m]1>
wayback-compositor doesn't do the scale thing
<dramforever[m]1>
so it won't be blurry
<mccd>
Ah nice
<bigmac>
f_: I see, thanks. I tested your branch and it shows the version as expected. I am wondering - the log verbosity is being hardcoded to "LOG_INFO" currently, is that planned to change?
<dramforever[m]1>
mccd: oh, also try xwayland-satellite
<dramforever[m]1>
it might work better than your compositor's xwayland
<bigmac>
f_: What I actually meant is - we can be showing useful information on wayback-session launch (such as the version), but there's a lot of wayland logs pushing it out of screen. Out of the scope of the MR, just wondering (And I don't think it has anything to do with the verbosity actually, as it is Wayland logs it seems)
norwoodites has joined #wayback
pinskia has quit [Ping timeout: 260 seconds]
Rndy has joined #wayback
norwoodites has quit [Read error: Connection reset by peer]
pinskia has joined #wayback
<f_>
oh I'm not too worried about that bigmac
<f_>
The log verbosity might be configurable later on
<f_>
it's not a hard patch to write
<axtlos>
where is the log verbosity hardcoded?
<f_>
the wayback_log_init lines
<axtlos>
ah right
<axtlos>
yeah would be easiest to just have it an envvar
<axtlos>
WAYBACK_LOG_LEVEL, if thats null set to LOG_INFO, otherwise whatever it has
<f_>
oh I think it's probably better to have a -verbose flag
<axtlos>
that would work too i suppose
<f_>
it's what Xorg does
<axtlos>
true
<axtlos>
i wrote the log functions with heavy inspiration from wlroots, which uses envvars
<bigmac>
axtlos: if we had both a flag and env var for it, which would take priority
<axtlos>
we shouldnt have both
<bigmac>
By the way, does the suppression of wayland / wlroots logs work for you. To make it so after launching wayback-session only our logs get printed and the xwm's. If so, which env vars are you setting. I just spent around ten minutes searching for the verbosity setting env vars without success.
<bigmac>
(and perhaps only wayback's?)
<dramforever[m]1>
no i don't think you can set the loglevel yet
<bigmac>
That should be independent of wayback
<bigmac>
I tried returning immediately in default_log_func and the log still gets printed, that's what leads me to that conclusion
<dramforever[m]1>
so the compositor logs through wlr_log and there's wlr_log_init(WLR_DEBUG, NULL); on the start of main in wayback-compositor
<bigmac>
Oh
<bigmac>
Do you know whether or not one can overwrite it with an env var?
<axtlos>
wlroots doesn't have an envvar to change the verbosity it seems
<axtlos>
i misremembered
<dramforever[m]1>
wlroots doesn't env var handling, we'd have to do it ourselves
<dramforever[m]1>
handling for verbosity i mean
<axtlos>
considering that wlroots doesn't do envvars we should just use commandline options
<dramforever[m]1>
is it just me being too deep in this rabbit hole or does x11/wayland "server" and "client" perfectly make sense to anyone else
<bigmac>
I think that what axtlos proposed is more understandable. It is saying that the flow is the same as with xorg, but there's a few layers on top. But yeah. I suppose it's hard to be on point and also easily understandable in four rectangles and two arrows. I think that it would also be worth it, if we're going to put it on the website or into the readme, to include something about the wayland being
<bigmac>
the one communicating with hw after translating x11 calls (show it side by side with xorg). It could both showcase the architecture and explain the point in one image. Neither of the diagrams do it currently imo
<bigmac>
just my opinion, probably not too deep in the rabbit hole as you are dramforever[m]1 *(yet)* haha
<dramforever[m]1>
if you put "wayland" and "x.org server" at the same level i'm going to keep complaining
<mccd>
Another question: does wayback improve the security of xorg? For example it's very easy to install a keylogger in xorg
<dramforever[m]1>
no, and it is intentional that we don't
<dramforever[m]1>
this is there to support legacy applications and "improve security" is "breaking old workflows"
<mccd>
makes sense
<dramforever[m]1>
if we do get protocols for controlling these in the future xwayland can implement them
<dramforever[m]1>
and we'd get that for free because we just use xwayland
<mccd>
Yeah that also makes sense
thollief has joined #wayback
mojo_ has quit [Ping timeout: 260 seconds]
pinskia has quit [Read error: Connection reset by peer]
<axtlos>
dramforever[m]1: just to be sure, this essentially 'converts' wayback-compositor into the signal handler, instead of using a custom one?
<dramforever[m]1>
in the sense that it handles exits, yes
<dramforever[m]1>
but it's based on fd close, not actual SIGCHLD/SIGTERM
<axtlos>
right yeah, but the effect is the same
<dramforever[m]1>
I had a blurb earlier explaining what happens if each of the three exits but I don't think it helps all that much to convince you it works
<axtlos>
oh no i can already tell what happens
<axtlos>
im honestly happy to move away from the custom signal handler
<axtlos>
not particularly proud of that code, but i wasnt aware of any better way
<dramforever[m]1>
a cleaner way would be to use sigwaitinfo to grab the ... signal
<dramforever[m]1>
which avoids having to run signal handlers altogether
<axtlos>
oh interesting
<axtlos>
though your solution is even better
<dramforever[m]1>
i tried converting wayback-session to that but it wasn't better
<axtlos>
i dont think wayback-session can be improved much
<axtlos>
actually
<axtlos>
hmm
<axtlos>
let me try something
<dramforever[m]1>
it should be a shell script
<dramforever[m]1>
or some non-shell script
<dramforever[m]1>
but the idea was we're going to get rid of it anyway so meh
<axtlos>
yeah tbh its best to just leave it rn
<dramforever[m]1>
i'll test this thing more tomorrow
<navi>
would be neat if Xwayback could just exec directly into Xwayland
<navi>
but that will depend on how xinerama will work
<axtlos>
yeah
<axtlos>
right now it would be possible
<axtlos>
im trying to make wayback-session exec directly into the session cmd, but that seems to not work properly
<axtlos>
the -terminate flag seems to only terminate xwayland when every client has exited, so any apps running in the session will keep it alive, even if the wm/de is exited
<navi>
you can look at xinit
<navi>
it does manage to do that, but i'm unsure how
<axtlos>
oh true
<dramforever[m]1>
i think xinit just does not directly exec
<navi>
(though the better thing is just to make xinit and startx handle Xwayback as another X server binary name)
<dramforever[m]1>
it waits for the session to exit and then kills the x server
<axtlos>
navi: yes that's what we're working on in the long term
<axtlos>
startx does already work somewhat
<axtlos>
nevermind, seems to be broken again
<navi>
xinit has a hardcoded list of X servers
<navi>
we'd need to add ours there
<axtlos>
ah right, startx doesn't work because it adds the vt arg which xwayland doesn't accept
<axtlos>
navi: i just have a symlink from /usr/bin/X to Xwayback and xinit works
<navi>
oh
<navi>
hmyeah that works
<navi>
the vt arg should be doable by passing it to wayback-compositor, and then there's a wlroots api to change vt i think
<axtlos>
thre is, we use it to allow for vt switching
<axtlos>
wlr_session_change_vt
<axtlos>
let me implement that rq actually
norwoodites has joined #wayback
pinskia has quit [Ping timeout: 248 seconds]
<axtlos>
ah nevermind, seems like wlroots doesn't implement that
<axtlos>
wlr_session_change_vt doesn't actually change where the compositor is launched
<axtlos>
i guess i could do it manually via an ioctl before any wlroots stuff is done
<Consolatis[m]1>
might be the best option to keep being libseat backend agnostic
<Consolatis[m]1>
switch the vt*
<ConanKudo[m]1>
note that libseat cannot switch VTs anymore
<ConanKudo[m]1>
the functionality was ripped out some time ago
<axtlos>
I mean either way I don't think it'd help us
<axtlos>
if the ioctl VT switch doesn't change the VT it renders on I don't think any other method of switching vts will
<axtlos>
my guess is that we'd have to relaunch wayback on the new vt for it to work
pinskia has joined #wayback
norwoodites has quit [Ping timeout: 272 seconds]
<Consolatis[m]1>
conan_kudo:matrix.org: I am confused. If libeat can't switch the VTs anymore how does wayback (and other wlroots based compositors) then switch the VT by calling into libseat?
<Consolatis[m]1>
libseat*
<ConanKudo[m]1>
they don't
<ConanKudo[m]1>
VT switching is done elsewhere
<Consolatis[m]1>
yes, assumingly via the libseat backend
<ConanKudo[m]1>
nope
<ConanKudo[m]1>
well previously yes
<ConanKudo[m]1>
if libseat doesn't call to logind, no VT switching happens
<ConanKudo[m]1>
this is one of the reasons KWin is never going to use libseat
<ConanKudo[m]1>
it's really not equivalent for us
<ConanKudo[m]1>
now as a wlroots based thing, I think we are more or less stuck with libseat? so we will need our own code to perform what libseat used to do
<ConanKudo[m]1>
in addition to libseat doing the seat thing
<ConanKudo[m]1>
admittedly it's not like libseat doesn't have a good reason to not do it: it wants to work on Linux environments that lack VTs
<Consolatis[m]1>
couldn't libseat be extended for further backends / re-establishing support for VT switch in the seatd backend?
<ConanKudo[m]1>
in theory, yes?
<ConanKudo[m]1>
in practice, I don't think Kenny will allow it
<ConanKudo[m]1>
he seemed pretty adamant when I asked him about it months ago that he didn't want that functionality
<ConanKudo[m]1>
I don't expect a ConsoleKit2 backend to show up in libseat either for similar reasons
<Consolatis[m]1>
hm. so basically it requires logind
<ConanKudo[m]1>
to do the right thing? yeah
<Consolatis[m]1>
^ for wayback to change the VT before starting up the compositor that is
vyivel has left #wayback [#wayback]
<dramforever[m]1>
mccd: no hurry but did you try xwayland-satellite? i'm curious to see if it works for you. it should be non-blurry... i think
<navi>
i'm not finding in seatd the change that removed vt switching from the seatd backend, the ioctl call to VT_ACTIVATE is still there