grufwub has quit [Remote host closed the connection]
grufwub has joined #wayback
<axtlos>
navi: not necessarily, it allows you to have a smaller, more generic kernel build and supply the required kernel modules in the initramfs and is practically required for a luks encrypted root
<axtlos>
are you able to launch any other compositor from the tty?
<axtlos>
like sway for example
<Saijin_Naib[m]1>
no idea, I only have wayback, xfce, and whatever else setup-wayland-base provided
<Saijin_Naib[m]1>
I can try sway, I guess
<Saijin_Naib[m]1>
sway gives similar xcb error
<Saijin_Naib[m]1>
Openbox works
<axtlos>
ok so its not a wayback issue but a general wayland issue for you
<axtlos>
is DISPLAY set?
<Saijin_Naib[m]1>
Mmm
<axtlos>
only reason i can think of why its trying to open in a nested X11 window is that it sees DISPLAY being set
<Saijin_Naib[m]1>
echo $DISPLAY shows :0.0
<axtlos>
yeah that would be the issue then
<Saijin_Naib[m]1>
I shouldn't have that?
<axtlos>
well assuming you're in a tty, and there is no display manager or X session running, no
<axtlos>
optimally you should figure out why its still set to :0.0, but if you just wanna get wayback running you can simply unset DISPLAY and it should work
<Saijin_Naib[m]1>
Well, that is exciting that it worked
__0x1eaf has joined #wayback
norwoodites has joined #wayback
pinskia has quit [Ping timeout: 265 seconds]
pinskia has joined #wayback
norwoodites has quit [Ping timeout: 272 seconds]
<navi>
axtlos: i meant that in a "if you setup already builds a minimal kernel that does all you need it to
<navi>
" kinda way
<f_>
I wonder if I should write docs on how to get wayback running on 'bare' alpine
<f_>
its requirements are nothing special but might be for people who never tried wayland before
f_|ic has joined #wayback
<dok>
i would be interested to read such thing
<axtlos>
navi: oh yeah then you're right
<Consolatis[m]1>
that hardcoded libexec path for wayback-compositor is slightly weird IMHO. Why not a usual executable in $PATH? makes testing much easier as one doesn't need to meson install nor needs to set env vars but just symlink the 3 executables into ~/bin/. Ended up modifying meson.build to make that work.
<Consolatis[m]1>
another thing I noticed is that currently its not possible to use the nested wayland backend of wlroots because the WAYLAND_DISPLAY env var is cleaned too early, so it falls back to the nested X11 backend. are you up for an MR to allow using the wayland backend?
<f_>
Consolatis[m]1: Well we need to make sure it's unset for things running in the compositor..
<f_>
Maybe the compositor can explicitely clean it up for things running inside it instead of having Xwayland do that
<axtlos>
Consolatis[m]1: RE: libexec stuff; this is done on purpose, wayback-compositor isn't meant to be executed by the user directly, which is what libexec is made for
<f_>
But we also need to ensure that it is not set in the session
<Consolatis[m]1>
f_: from a quick glance it looks like wayback-compositor doesn't actually start anything. and when testing WAYLAND_DISPLAY is not set within the x11 session
<f_>
Yes, it doesn't start anything
<f_>
hm, maybe it's enough to just unset it in wayback-session before running the env
<Consolatis[m]1>
i just moved unsetenv("WAYLAND_DISPLAY") after the wayback-compositor fork and things seem to work well
<f_>
awesome.
<f_>
Yeah so feel free to submit an MR
<Consolatis[m]1>
done
<Consolatis[m]1>
re libexec: alright, if that is how things are intended I'll just keep my meson.build changes locally or use the env var
<f_>
I personally use the envvar when I need to use a specific binary
<f_>
MR LGTM, by the way
<f_>
now we just wait for someone to merge it :p
<Consolatis[m]1>
i do have to modify my local meson.build anyway because I build wlroots as subproject and my meson version doesn't appear to like a add_global_arguments() after executing a subproject
<Consolatis[m]1>
could also create a PR to fix that if interested
fitrh has joined #wayback
<navi>
Consolatis[m]1: re: why not an exectuable in PATH -- because wayback-compositor is an implementation detail that should not be invoked by users, binary in PATH share a global namespace and are meant to be user facing, like Xwayback and wayback-session
<navi>
i do intend to improve how meson handles the wayback-compositor though
<navi>
to make non-installed uses easier
<f_>
It's supposed to be working as an X Server, it using wayland internally is just a minor detail ;)
<f_>
or: WindowMaker in IceWM in WindowMaker in IceWM
HadiChokr[m]1 has quit [Quit: Idle timeout reached: 172800s]
__0x1eaf has joined #wayback
<Consolatis[m]1>
being able to run nested eases testing future multiple output support btw, WLR_WL_OUTPUTS=2 for the wayland backend and WLR_X11_OUTPUTS=2 for the X11 backend. resizing the nested window is also fun
<Consolatis[m]1>
resizing nested outputs can be handled via the wlr_output->events.request_state event
<Consolatis[m]1>
oh, sorry. request_state is actually already implemented
<Consolatis[m]1>
there still seems to be missing something, at least mate-session is just scaled weirdly if decreasing the nested window height
<axtlos>
Consolatis[m]1: yes, the actual x display doesn't change its resolution with the wayback compositor window, so it'll always stay with the initial geometry when first launching it
f_|ic has quit [Quit: Connection closed for inactivity]
<Consolatis[m]1>
i see. just playing around with this a bit. seems all that is required is for the compositor to reconfigure the toplevel to the new layout size
<Consolatis[m]1>
I don't intend to work on it further but feel free to take things you want from the branch (or not), up to you
<axtlos>
what do you mean with "adds multiple outputs"?
<Consolatis[m]1>
well, support for running with multiple monitors
<axtlos>
as in xinerama support?
<Consolatis[m]1>
no, nothing on the X11 side
<axtlos>
oh
<Consolatis[m]1>
it basically just stops using fullscreen and hardcoding the geometry for Xwayland and instead updates the size of the xwayland xdg toplevel dynamically
<Consolatis[m]1>
so it will likely have issues with differently sizes outputs without some X11 side support for xinerama
<Consolatis[m]1>
^ a proper implementation should also use the wlr_output_layout.events.change signal instead of sprinkling update_xwayland_size() everywhere, one is also missing for the output destroy handler. As said, its really just a quick proof-of-concept
<axtlos>
ohh ok i see so it just stretches the xwayland window over every monitor
<Consolatis[m]1>
basically
tomate has joined #wayback
<Consolatis[m]1>
I think that is the only option wayback has. It just needs to somehow tell the X11 side about the actual screen layout so "dead" zones aren't used
<axtlos>
i mean yeah, that's how xinerama works
<Consolatis[m]1>
force pushed a fixup for the missing output destroy handler and also added output mapping for absolute pointers so nested multi-output mouse events work correctly
<f_>
axtlos: RE !67, why are you getting rid of getopt?
<f_>
getopt_long_only supports '-opt thing', that's why I switched to it
<axtlos>
because getopt doesn't allow for the argument style that xorg has
<axtlos>
xorg also does '+opt'
<f_>
Aha
<f_>
got it then
<axtlos>
im not sure if anyone actually uses XDM, but it works with Xwayback at /usr/bin/X now
<f_>
oh awesome
<axtlos>
lightdm doesn't properly launch the greeter for some reason
<f_>
I just use greetd myself
<axtlos>
yeah same
<f_>
kinda cheating with sway running for the greeter hehe
<axtlos>
just wanted to see how many X programs work with Xwayback at /usr/bin/X
<f_>
yeah that's nice
<f_>
tbh xorg's args style is weird
<axtlos>
yeah i dont like it
<axtlos>
Xorg compat makes me program things i would never dare to do
<f_>
but eh, we're aiming for compat, so don't have other choices :p
* f_
wondering if we can't somehow add some stuff here and there that's not in xorg, wrt to CLI, while still being compatible with whatever xorg does
<Consolatis[m]1>
it seems to also provide a webhook target for gitlab events
__0x1eaf has quit [Quit: Lost terminal]
<ConanKudo[m]1>
"gitlab hook forwarder" is definitely not what comes to mind when I see "glhf"
<f_>
Consolatis: I'll see if I can bring one sometime.
<f_>
Oh sounds easy to do, that's nice
<f_>
With approval from the others I'll see if I can bring mine in upcoming days.
<axtlos>
would certainly be useful for linking issues and merge requests
<axtlos>
i wouldnt mind it
<ConanKudo[m]1>
I don't care one way or another
anabelae[m] has joined #wayback
<anabelae[m]>
Hi. Pardon my stubbornness, but is Wayback a compositor running xwayland in rootful mode? Quoting the wayland book "Xwayland compatibility compared to a native X server will probably never reach 100%. Desktop environment (DE) components, specifically X11 window managers, are practically never supported. An X11 window manager would not know about native Wayland windows, so it could manage only X11 windows." <- is this what Wayback is
<Consolatis[m]1>
or accepting wayland clients via the usual compositor but create fake X11 windows for them and synchronize their state
<Consolatis[m]1>
but that would mean that not all X11 functions would work correctly like screensharing. with something like 12to11 I assume that would work as well
<ari>
out of curiosity, what currently happens under wayback (+ some X11 WM running in the rootful Xwayland) if someone runs a wayland-native app?
<navi>
nothing
<Consolatis[m]1>
nothing, it wouldn't work because the wayland compositor is not exposed to the X11 environment
<navi>
wayback doesn't create a socket in rundir
<navi>
so the client would not find any way to talk to the compositor, the only socket we make is inherited directly to xwayland via exec