<bigmac>
f_: "bigmac: I can reproduce it just fine on my laptop" - I was just able to reproduce it, but only when running wayback as system compositor. When running unfullscreened as a session compositor I am not able to do so.
<axtlos>
yes the issue only happens when running wayback as a system compositor
<bigmac>
In the xserver patch there's mentioned "rootful Xwayland window receives an xdg-surface configure
<bigmac>
event before the output definition is complete
<bigmac>
I would assume this is what we'd have to change for it to start working with versions without the patch present?
fossdd has joined #wayback
<f_>
bigmac: Oh, yes I run Wayback as a system compositor
<f_>
actually I'm currently typing from it :)
mebious has quit [Remote host closed the connection]
spicywolf has quit [Remote host closed the connection]
wolfdog has quit [Remote host closed the connection]
staceee has quit [Remote host closed the connection]
paper has quit [Remote host closed the connection]
<f_>
Also I quickly checked this morning and the Wayback repo is at 150+ commits now so that's nice :)
<dramforever[m]1>
f_: before i forget, i remember you were asking about posix_spawn right?
<dramforever[m]1>
it's a mostly theoretical concern in correctness, but in a way that using posix_spawn means we'll never have to think about
<dramforever[m]1>
man fork.2 says in a multi-threaded program fork can only call async-signal safe functions before doing exec
<dramforever[m]1>
sure, what we're doing is definitely single threaded, as long as we're not on macos
<dramforever[m]1>
but with posix_spawn we'll never have to think about this in the future, when we possibly bring in more dependencies into our glorified shell script
<f_>
ok
<f_>
makes sense
<dramforever[m]1>
one practical thing that already can happen is the exec failure wlr_log
<dramforever[m]1>
which runs in the child, and thus races with the parent on stderr
<f_>
thomas_adam: and seeing how skeptical you are regarding what I currently have implemented I'd be curious to hear your thoughts on why you are skeptical on this
<axtlos>
f_ ConanKudo[m]1 navi: do you know if the viewporter protocol is required for wayback? it currently definitely doesn't need it but idk if we may need it for the future
<ConanKudo[m]1>
IIRC doesn't Xwayland use it already?
<axtlos>
what do you mean?
<axtlos>
xwayland does use viewporter, but according to bigmac it's not required
<axtlos>
otherwise a fix is to remove the -fullscreen argument
<dramforever[m]1>
now that we pass -terminate to, is there any reason for the weird handling with comp_pid and stuff anymore?
<dramforever[m]1>
to Xwayland, i mean
<Consolatis[m]1>
i think viewporter only makes sense for -hidpi. And as wayback isn't supporting wayland output scaling anyway its pretty useless. note that removing the viewporter protocol from wayback papers over the actual bug in xwayland
<axtlos>
yes, we need to properly terminate the compositor when Xwayland terminates
<axtlos>
Consolatis[m]1: What do you mean with 'papers over the actual bug'?
<axtlos>
im not sure what 'papers over' means
<Consolatis[m]1>
"hides it" / works arounds it
<axtlos>
ohh
<axtlos>
yeah i figured
<axtlos>
i assume same thing for the alternative solution of removing the -fullscreen flag
<Consolatis[m]1>
the bug in xwayland is that it doesn't correctly removed output globals and then violates the viewporter protocol by sending a invalid destination geometry
<Consolatis[m]1>
only kind of for the specific case of starting up. but apparently not when the used fullscreen output is gone
<axtlos>
ok wait so if i understand you right this isnt an issue with wayback?
<Consolatis[m]1>
nope
<Consolatis[m]1>
wayback is completely fine here I think
<axtlos>
oh hm
<axtlos>
i mean either way we should probably remove the fullscreen option used for Xwayland
<axtlos>
specifying both geometry and fullscreen seems kinda redundant
<Consolatis[m]1>
yeah, and the viewporter protocol also doesn't really seem necessary considering that wayback doesn't support wayland output scaling
<Consolatis[m]1>
in general: I'd remove the fullscreen argument, the geometry, the viewporter support. then react to wlr_output_layout changes and reconfigure the xdg-toplevel representing xwayland
<axtlos>
oh also remove geometry?
<axtlos>
interesting
<Consolatis[m]1>
then figure out some side-channel to tell xwayland about the different outputs via xrandr --setmonitor
<axtlos>
i dont think xrandr --setmonitor is the way to go
<Consolatis[m]1>
why not?
<axtlos>
a lot of window managers use xinerama instead of randr
<Consolatis[m]1>
can it be configured from a client as well?
<axtlos>
i'm not sure
<Consolatis[m]1>
or just from xwayland/xorg itself
<axtlos>
but generally from what ive seen if something uses xinerama its not reliable to use xrandr --setmonitor
<Consolatis[m]1>
I see. I only tested it with mate-session where it seems to work
<dramforever[m]1>
axtlos: i would have thought it's easier to just do wl_display_terminate on client disconnection in the compositor
<dramforever[m]1>
unless you're trying to reuse the same wayback-compositor...?
<axtlos>
how will wayback-compositor tell if the client disconnected
<axtlos>
oh yeah right we also need it to keep Xwayback alive
<axtlos>
Xwayback exits when either the compositor or Xwayland exits
<dramforever[m]1>
i think wl_client_add_destroy_listener
<dramforever[m]1>
yeah in wayland-server.c when we get a WL_EVENT_HANGUP it does wl_client_destroy on the client
<dramforever[m]1>
and we can listen to thay
<f_>
Consolatis[m]1: yeah also to me xrandr --setmonitor feels more like a hack than a proper solution to me
<dramforever[m]1>
and we just call wl_display_terminate on that, which really is just setting a flag to make the event loop terminate
<f_>
Ideally it would be awesome to actually be able to configure displays from Wayback
<f_>
like, changing resolutions and refresh rates etc
<dramforever[m]1>
backing up a bit, the handle_segv function currently just returns after handle_exit, which cannot possibly be right
<dramforever[m]1>
so like if you force a null pointer deref in xwayback it does some very funny things like printing the message multiple times (so evidently retrying the faulting instruction several times), which can't be right
<dramforever[m]1>
and, well, maybe i care too much but when i see something like this i don't like "just fixing" it, i want to get rid of this non-obvious code altogether
dramforever[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Consolatis[m]1 has quit [Quit: Bridge terminating on SIGTERM]
ConanKudo[m]1 has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
anabelae[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #wayback
dramforever[m]1 has joined #wayback
<dramforever[m]1>
i think i've convinced myself i can do this process handling entirely based on wayland server api telling me "hey client dropped". maybe tomorrow.
<f_>
no there's no webhooks thing for site, don't think it's really necessary
<axtlos>
added a quick style review, im not the best writer but imo multiple ands in one sentence sounds weird
<f_>
I'm not a native english speaker :P so these are absolutely welcome
<axtlos>
yeah im not a native speaker either lol
<dramforever[m]1>
> e.g. mouse locking (very useful in first-person shooters and used by XScreenSaver)
<dramforever[m]1>
oh i should try gaming on wayback
<dramforever[m]1>
* e.g. mouse locking (very useful in first-person shooters and used by XScreenSaver)
<dramforever[m]1>
oh i should try gaming on wayback
<f_>
apart from the mouse stuff it works .. freedoom works just fine
<dramforever[m]1>
* > e.g. mouse locking (very useful in first-person shooters and used by XScreenSaver)
<dramforever[m]1>
oh i should try gaming on wayback
<dramforever[m]1>
oh crap sorry this is an irc bridge i shouldn't have been doing loads of minor edits
<dramforever[m]1>
oh, re: xinerama vs xrandr earlier, my data points are that i3 handles xrandr --setmonitor, kwin doesn't (no effect)
<dramforever[m]1>
i also don't know how kwin managed to handle the scaling thing... but it works
ConanKudo[m]1 has joined #wayback
<ConanKudo[m]1>
kwin does it on its own
<ConanKudo[m]1>
it always has
<ConanKudo[m]1>
<dramforever[m]1> oh, re: xinerama vs xrandr earlier, my data points are that i3 handles xrandr --setmonitor, kwin doesn't (no effect)
<ConanKudo[m]1>
this functionality is not expected to work on kwin
<ConanKudo[m]1>
it is a bug if it does
<dramforever[m]1>
so no xrandr for kwin?
<ConanKudo[m]1>
xrandr yes, but kwin mediates it through kscreen
<ConanKudo[m]1>
it forces its own management through that
<dramforever[m]1>
ah
<dramforever[m]1>
partial xrandr for kwin
<ConanKudo[m]1>
this has always been the case, since kwin was not X11 only even back before Wayland
<dramforever[m]1>
so basically kwin just does its own thing on understanding what monitors are?
<ConanKudo[m]1>
yup
<ConanKudo[m]1>
kwin, mutter (and forks), and xfwm4 all are like this
<ConanKudo[m]1>
xrandr didn't always exist, and metacity and kwin both developed their own understanding of outputs before xrandr
<ConanKudo[m]1>
i3 and most of other simple wms never did that, so ironically that makes more of xrandr's features work (with the possible caveat that the wm cannot handle some of what xrandr does)