<f_>
it would seem that they are actually undefined and wl_list_remove is called on them
<f_>
and it obviously fails
<dramforever[m]1>
and this is a problem... just in general but specifically for wayback i think wayback really doesn't like that? depending on what exactly i'm doing i get either the display going back to the builtin screen or it just exiting
<f_>
The reason why it only happens on ctrl-alt-backspace is because the other methods of closing don't seem to actually cleanup things
<dok>
f_ thank you for figuring this out
<dramforever[m]1>
exiting might just be kwin getting confused
<f_>
dok: thank you for helping out :) it was a team effort
<f_>
dramforever[m]1: I test on WindowMaker and IceWM
<dramforever[m]1>
i don't get that if i only have xterm
Consolatis[m]1 has joined #wayback
<Consolatis[m]1>
f_: re wl_list_remove(): yeah, that looks pretty much broken. As they apparently aren't used they can just be removed. In situations where a listener might be needed depending on some condition one can call wl_list_init(&listener.link) on init, that allows safe removal
<f_>
but I believe that's an unrelated issue that just popped in because it no longer segfaults this early
<Consolatis[m]1>
that is expected from wlroots 0.19.x. It now checks for empty signal listener lists on destroy
<f_>
Ah.
<Consolatis[m]1>
so its missing some wl_list_remove() of an installed listener and is unrelated
<f_>
Yeah
<f_>
tbh better than it segfaulting earlier :p
<dramforever[m]1>
the display moving back to the builtin screen still happens with only xterm though
<f_>
dramforever[m]1: ..yeah not sure that's going to be fixed..
<f_>
your monitor is acting up, and this is a stop-gap workaround anyway
<f_>
the better solution is to plumb xinerama properly so wayback actually gets multimonitor support
<dramforever[m]1>
yeah hopefully getting actual multi display support would fix it
<f_>
and btw, this is the reason why I don't daily drive wayback right now with my two displays
<Consolatis[m]1>
JFYI, monitors being removed and "reconnect" can be tested by switching VTs with wlroots 0.19.x
<f_>
the new envvar WAYBACK_DISPLAY also won't work at all for my setup
<f_>
at least with it I can't run wayback on my main monitor
<f_>
because thanks to my GPU my laptop can only handle 2 displays at a time and I also have a VGA monitor plugged in, and when the laptop display is turned on VGA takes precedence over DisplayPort so my main display is also the display that's off when it can't drive any more displays
<f_>
and I think wayback doesn't (yet) turn off unused displays, so yeah ...
<dramforever[m]1>
this weird monitor behavior can also be observed on normal kde
<dramforever[m]1>
where when i wake my laptop from idle the monitor disconnects, and now it thinks since the lid is closed and the monitor is disconnected it's time to sleep...
<Consolatis[m]1>
some monitors do act weird. labwc had reports about monitors disconnecting on modeset, disconnecting on DPMS resume, all kind of weird stuff
<f_>
dramforever[m]1: I think I had these kinds of problems ages ago, that's why I completely disable suspend on closing lid :p
vyivel has joined #wayback
<f_>
Consolatis[m]1: all sorts of fun I guess.
vyivel has quit [Remote host closed the connection]
vyivel has joined #wayback
vyivel has quit [Remote host closed the connection]
vyivel has joined #wayback
<f_>
thankfully my monitors don't seem to do that I think, at least not usually
<Consolatis[m]1>
technically the best approach is likely for a compositor to keep the outputs around and try to re-match them on connect (by connector + name + description + make + model + serial) and then apply the stored settings from their last appearance. for example their positions in the output layout
<f_>
Consolatis[m]1. I wouldn't worry too much about it
<f_>
like I said WAYBACK_DISPLAY is just a workaround for now
<dramforever[m]1>
technically the best approach is to actually handle multiple monitors yes
<dramforever[m]1>
we don't have that yet this is a known thing
<f_>
yep dramforever[m]1. ^^
<Consolatis[m]1>
its unrelated to the WAYBACK_DISPLAY, this topic will come up again even if supporting multiple outputs
<dramforever[m]1>
yes it will
<dramforever[m]1>
we deal with it then
<dramforever[m]1>
we can't do much about it now because we just barely know about monitors
<f_>
Consolatis[m]1: yeah I think so too but I mean I wouldn't worry about that *now*
<axtlos>
any specific reason you're using postmarketos on a regular laptop?
<f_>
makes it easier to develop for postmarketOS
<axtlos>
oh yeah makes sense
<f_>
and also kinda dogfooding :p
<f_>
though overall apart from the merged-usr my install is not much different from alpine
<axtlos>
is merged usr something postmarket does or did you manually set that up?
<f_>
I did it manually
<axtlos>
oh i see
<f_>
there's a script in alpine that does it. Eventually pmOS and alpine will get merged-usr by default
<axtlos>
i assume pmOS will switch to it with the systemd migration?
<f_>
I did it to confirm that the script works :P
<axtlos>
iirc systemd needs merged-usr since last year
<f_>
pmOS is not migrating to systemd
<axtlos>
oh? i thought i read something about that
<f_>
It will be supported alongside openrc
<axtlos>
ohh
<f_>
unless the plan changed :p
Achill[m] has joined #wayback
<Achill[m]>
currently we patch our systemd to work with non-usr-merged systemd and thats what we ship in our latest release, but eventually we want to drop it and usr-merge all systemd installations
<f_>
Achill[m]: why not usr-merge everything? :p
<f_>
instead of just systemd installs
<Achill[m]>
thats the plan
<axtlos>
yeah no i just checked the blog post i read and it does mention being able to chose
<axtlos>
thtas nice though
<f_>
yep
<arraybolt3>
fwiw I saw Adelie Linux is apparently getting systemd to build against musl libc and apparently got split-/usr back?
<Achill[m]>
the best part is doing it upstream in alpine, so we actually bring alpine forward and work on the right pieces
<f_>
that's not really a dealbreaker for me, I don't really game on this laptop
<Ariadne>
arraybolt3: alpine tries to be "evergreen", which means we have to be careful about anything which may break user experience
<navi>
fwiw there are current (embedded) users of adelie, and probably alpine too, that mount /usr during boot, and literally don't have enough ram for a initramfs
<navi>
which is why openrc also supports both and will continue to do so
<navi>
(we default to merged-usr just for /usr/libexec, but that can be changed by just `meson setup build -Dlibexec=/lib`)
<f_>
How much ram?
<navi>
i dunno
<navi>
i was just told that initramfs are no go due to not enough ram
<navi>
by an adelie dev
<f_>
pmOS runs on devices with as little as 256MB of RAM
<f_>
and for space-constrained /boot it's split into two
<f_>
anyway afk
<axtlos>
I know from experience with embedded devices that even when there is enough ram that the initramfs is often skipped since it adds unnecessary complexity to the system
<axtlos>
in most cases an initramfs is required to provide specific kernel modules to be able to get to the real root, for embedded devices that's unnecessary since the kernel is specifically built for the hardware, so it's easier to just have the needed stuff in the kernel build
grufwub has quit [Read error: Connection reset by peer]
grufwub has joined #wayback
<navi>
adding a initramfs to your image build process just to mount /usr seems like a lot