f_ changed the topic of #wayback to: Wayback - a wayland-based X11 environment | https://wayback.freedesktop.org/ | src: https://gitlab.freedesktop.org/wayback/wayback | logs: https://libera.catirclogs.org/wayback | matrix bridge: #wayback:catircservices.org
grufwub has quit [Remote host closed the connection]
grufwub has joined #wayback
_whitelogger has joined #wayback
_whitelogger has joined #wayback
norwoodites has joined #wayback
pinskia has quit [Ping timeout: 245 seconds]
Saijin_Naib[m]1 has quit [Quit: Idle timeout reached: 172800s]
<axtlos> anabelae[m]: displayfd makes Xwayland automatically select a display name and then send it over the file descriptor passed as the argument, the reason it works for you is because it's selecting a new display name
<axtlos> hence I asked you what command you're running, if you already have xwayland running somewhere else you need to specify an unused display name
<f_> Try with display :3
<f_> It should work
<f_> Favourite X display name :3
<axtlos> we should make that the default display name actually !!
<f_> hehe
<anabelae[m]> meow
<anabelae[m]> setting it to anything but 0 works! makes sense
<Wayback> @a​xtlos opened merge request: !68 Don't require display to be explicitly set (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/68)
lanodan has quit [Ping timeout: 252 seconds]
lanodan has joined #wayback
__0x1eaf has joined #wayback
pinskia has joined #wayback
norwoodites has quit [Ping timeout: 260 seconds]
<f_> > Xserver doesn't require users to explicity set the DISPLAY name, instead it automatically finds the next available one automatically.
<f_> Oh really? Whatever it does for that never worked for me I guess?
<f_> TIL
<axtlos> huh interesting
<dok> about the #44: i would expect from my X implementation that switching vt and using .xinitrc to work
<Wayback> #44 Criteria for an initial release (https://gitlab.freedesktop.org/wayback/wayback/-/work_items/44) [opened]
<f_> dok, oh yes of course
<f_> I've been meaning to try and reproduce your issue
<axtlos> what issue?
<f_> Apparently switching VTs makes wayback crash
<dok> #50
<Wayback> #50 protocol error when switching terminal (https://gitlab.freedesktop.org/wayback/wayback/-/issues/50) [opened]
<f_> "Initial release" means in this case alpha 0.1
<dok> and i am having another issue when my .xinitrc contains `xset ...` before exec
<dok> not reported yet
<axtlos> oh yeah I may know how to fix the vt issue
<dok> \o/
<axtlos> but I won't be home for like 2-3 hours so it'll take a while until I can try
<f_> No worries
<dok> it's alright
<axtlos> what happens with xset? does it crash or just ignore them?
<dok> let me try again
<dok> "cannot open display"
<axtlos> that's weird
<axtlos> just having exec dbus-launch-session dwm works?
<dok> yes... at least exec dwm does, with dbus-launch-session i am less sure
<dok> yes it does
<dok> and with only `xset b off` before the exec, it no longer works
<axtlos> can't think of any reason why that fails right now
<axtlos> gotta look into it later
<dok> i can create an issu with this log
<f_> yeah that'd be awesome
<anabelae[m]> Executing i3 just before starting the wayland event loop opens it up, but from within it's still reading as wayback-compositor (at least in fastfetch), instead of the expected i3. Is it because it is not running as rootful?
<Wayback> @jmaselbas opened issue: #52 wayback-session fails when .xinitrc contains xset (https://gitlab.freedesktop.org/wayback/wayback/-/issues/52)
<dok> maybe it's a race condition
<dok> maybe the display is destroyed after the first xset
<dok> seems like only the first "XOpenDisplay" during .xinitrc works and all the other fails
<axtlos> oh that may be because of the sigchld handler then
<dok> uh
<axtlos> iirc sigchld isn't only for immediate children, but also for grandchildren
<axtlos> so wayback-session may receive a sigchld from the first xinitrc command and then quit the stuff after that
<axtlos> quit before*
<dok> if i do lsusb (not a shell cmd) before the exec it works just fine
<axtlos> huh
<dok> IIRC wayback-session do an exec sh .xinitrc
<axtlos> yes
<dok> so i think it's more related to wayback-compositor
<axtlos> I think it's more likely to be Xwayback
<axtlos> I'll have to do more testing later
<f_> anabelae, shows as sway for me on Icewm
<f_> I wouldn't worry about it though
__0x1eaf has quit [Quit: leaving]
caskd has quit [Ping timeout: 245 seconds]
caskd has joined #wayback
<Consolatis[m]1> I don't think wayback supports running xwayland rootless
<Consolatis[m]1> it does run xwayland rootfull in fullscreen
caskd has quit [Ping timeout: 252 seconds]
caskd has joined #wayback
<navi> which version of wayback is that?
<navi> sorry i'm lost and can't read backlog, but, `const char *socket = wl_display_add_socket_auto(server.wl_display);` shouldn't be happening anymore
<f_> anabelae: Xwayland runs rootful under Wayback, not rootless
<f_> Rootless = Xwayland as you see used usually in wayland DEs: you launch X11 apps in your wayland DE and they are integrated in your wayland DE
<f_> Rootful = More like running Xephyr inside X
<f_> So they are not to be confused :)
<navi> is there a reason we pass -retro to Xwayland when using displayfd, but not when passing a display value?
<ConanKudo[m]1> not that I know of
<ConanKudo[m]1> that should probably be controlled externally
<navi> it's an Xserver flag so yeah
<anabelae[m]> <f_> Rootless = Xwayland as you see used usually in wayland DEs: you launch X11 apps in your wayland DE and they are integrated in your wayland DE
<anabelae[m]> Thank you!
<anabelae[m]> <navi> sorry i'm lost and can't read backlog, but, `const char *socket = wl_display_add_socket_auto(server.wl_display);` shouldn't be happening anymore
<anabelae[m]> You’re good, I added it for development purposes. What is the preferred way now
<navi> wayback-compositor shouldn't create any sockets
<navi> Xwayback creates two unnamed/annonymous sockets with `socketpair` and passes the fd down to wayback-compositor
<navi> which then manually creates the clients from those sockets
<Wayback> @a​xtlos closed merge request: !68 Don't require display to be explicitly set (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/68)
<axtlos> navi: RE: retro; no, I must've missed it when adding the xorg style arguments
<navi> btw i have a PR ready in a moment with some cleanups
<f_> Oh yes, regarding -retro, is there any reason we pass it by default to xwayland at all?
<f_> navi: looking forward to it!
<navi> do we have any policy for VLAs?
<f_> VLAs?
<ConanKudo[m]1> variable length arrays
<f_> Ah
<ConanKudo[m]1> navi: not really
<ConanKudo[m]1> why?
<f_> Yeah not really no
<navi> some projects don't like it bc old compilers don't implement them properly
<navi> so if the same applied here i'd have to add a calloc on my patch
<ConanKudo[m]1> meh no
<ConanKudo[m]1> I'm already fairly tempted to raise the baseline to C23 anyway
<f_> Meh why support old compilers in the first place
<navi> oki good
<ConanKudo[m]1> I don't want us to get into the trap that wlroots has where it struggles to handle things from stricter compilers because they don't test well with new compilers and standards
<axtlos> f_: I assume Ariadne initially added it for testing, I removed it with the x args MR, but forgot to remove it for displayfd
<navi> i'll remove it on my PR in a moment
<f_> axtlos: alright
<Ariadne> i would prefer to avoid VLAs, they are a massive footgun
<ConanKudo[m]1> also.... I'd like to raise to meson minimum version so that I can raise the C standard version
<ConanKudo[m]1> meson 1.4 is available pretty much everywhere that we would reasonably care about
<f_> ConanKudo: I suppose feel free to do it, I don't have strong opinions about that as long as it builds on the decent linix distros out there
<f_> err, linux*
<f_> I hate on-screen phone keyboards
<navi> is there any distros still on gcc-13 that we care about?
<navi> afaik gcc-13 only goes up to c2x, not c23 proper
<navi> not sure
<f_> actually do we care about support on non-linux?
<navi> we should as long as wlroots does imo
<axtlos> I would prefer we do
<axtlos> I use freebsd a lot, wayback is pretty useful for the setups I have on it
<ConanKudo[m]1> C23 should be fine on all of those platforms
<f_> so far all I know is that FreeBSD and OpenBSD support wayland to an extent
<axtlos> freebsd works perfectly fine with wayland
<Wayback> @Conan_Kudo opened merge request: !69 meson: Raise the C standard to C23 and bump minimum version to 1.4.0 (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/69)
<navi> doing at least a build test on freebsd would be neat
<axtlos> openbsd works too, but I don't know the quality level
<navi> dunno if that's doable
<f_> "to an extent" was more about obsd TBH :)
<ConanKudo[m]1> it's not really doable
<navi> openrc uses cirrus for that
<navi> but it's sucky
<f_> Hmm yeah buildtesting on freebsd would be cool
<axtlos> I could do periodic tests on freebsd locally
<axtlos> if we aren't able to get a freebsd ci
<ConanKudo[m]1> we are probably not able to get any bsd CI
<f_> then maybe some selfhosted runner or something could do?
<ConanKudo[m]1> so if people want to test it there on their own and report stuff back, that's fine
<f_> But maybe that's a lot more complicated than it needs to be
<axtlos> I assume qemu doesn't work inside the fdo ci?
<f_> ConanKudo[m]1 yeah that's fair.
<ConanKudo[m]1> axtlos: I don't want to turn wayback CI into mesa CI
<ConanKudo[m]1> mesa CI is so byzantine and impossible to run externally
<axtlos> ok yeah thats fair then
<whitequark[cis]> is there anything like act for gitlab?
<whitequark[cis]> (act runs a github actions suite locally)
<f_> Yeah one could bring their own runners
<f_> But I don't know how hard that is
<whitequark[cis]> no no i mean you just do act push and it runs the testsuite locally as-if github did it
<whitequark[cis]> which is very useful for avoiding fifty thousand "fix ci (actually now)" commits
<ConanKudo[m]1> as far as I know, there is no equivalent
<f_> Ah
<Wayback> 6eeb0352 meson: Raise the C standard to C23 and bump minimum version to 1.4.0
<Wayback> 632a77a6 Merge branch 'raise-to-c23' into 'main'
<Wayback> @Conan_Kudo merged merge request: !69 meson: Raise the C standard to C23 and bump minimum version to 1.4.0 (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/69)
<f_> At pmOS we have a bootstrapping tool that also handles ci
<f_> And if you want to run ci locally you run 'pmbootstrap ci'
<ConanKudo[m]1> okay I'm not loving the commit push thing
<ConanKudo[m]1> maybe I'll drop that one
<f_> Yeah I don't think it's necessary
<f_> You can drop that from the webhooks stuff
<ConanKudo[m]1> done
<f_> good!
<whitequark[cis]> <Wayback> @Conan_Kudo merged merge request: !69 meson: Raise the C standard to C23 and bump minimum version to 1.4.0 (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/69)
<whitequark[cis]> nice
<Wayback> !69 meson: Raise the C standard to C23 and bump minimum version to 1.4.0 (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/69) [merged]
<ConanKudo[m]1> I expect that at the very least the BSDs will be able to handle this from within ports
<axtlos> handle the version bump?
<ConanKudo[m]1> the standard bump
<ConanKudo[m]1> and the meson version
<ConanKudo[m]1> (it already needed ports anyway for meson)
<f_> If it causes any issues (which I highly doubt it will) we can always lower it a little later
<f_> The standard ver that is
<axtlos> i mean wayback needs packages from the ports tree either way
<ConanKudo[m]1> yup
<f_> But I'm not interested in supporting old gcc versions and I don't think (m)any of you are
<f_> ;p
<ConanKudo[m]1> yeah I'm not either
<ConanKudo[m]1> even on EL there's always the option of newer gcc
<axtlos> what's EL
<ConanKudo[m]1> Enterprise Linux
<dramforever[m]1> what's debian stable on
<ConanKudo[m]1> e.g. RHEL and SLE
<axtlos> oh
<dramforever[m]1> if debian stable has it i think it's good enough
<ConanKudo[m]1> don't care about Debian 12, Debian 13 is releasing next month anyway
<ConanKudo[m]1> and Debian 13 has GCC 14
<f_> Wayback is still alpha-quality and bleeding-edge as of now so I think that's only fair.
<dramforever[m]1> i think if you're on RHEL just ask red hat to maintain Xorg
<ConanKudo[m]1> well RHEL 10 has GCC 14 too
<ConanKudo[m]1> and RHEL 9 has GCC 14 available as a sidecar package
<ConanKudo[m]1> SLE 15 default is GCC 11 I think? but it has newer GCCs available as alternative packages
<f_> why run Wayback in a production RHEL system anyway?
<ConanKudo[m]1> the only actual stale distribution where this is a problem is Debian
<ConanKudo[m]1> and Ubuntu
<f_> I'm sure there's a snap for that /j
<ConanKudo[m]1> f_: I probably wouldn't, but my go-to when it comes to qualifying "reasonable" old is the EL distributions
<Achill[m]> alpine edge is not on gcc 15 yet because i dont have time to debug the ada frontend failure :/
<ConanKudo[m]1> since they actually maintain their toolchains
<ConanKudo[m]1> unmaintained toolchains are the devil, and debian is a good example of this
<ConanKudo[m]1> once a debian release is out, that's pretty much it for them
<Wayback> @navi_desu opened merge request: !70 xwayback: simplify argument parsing and main body (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/70)
<dramforever[m]1> oh nice that also fixes the warnings on dropping const
<Wayback> @navi_desu opened merge request: !71 wayback-session: properly handle XWAYBACK_PATH (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/71)
joast has quit [Quit: Leaving.]
<navi> the argv in execv* functions is annoying tbh
<navi> it hard requires a cast if -Wwrite-strings is on
<dramforever[m]1> yes, it hates you and takes char * not const char *
<dramforever[m]1> i guess you can strdup_or_exit it
<navi> the problem is that in standard c, string literals are not const
<navi> and the api relies on that
<navi> and `const` doesn't propagate past one pointer (for valid reasons), so if the signature were `const char **`, then you wouldn't be able to use a `char **`
<navi> (but arguably, casting to const is less scary than casting to non-const)
<dramforever[m]1> that is true, but the string literal array should have been const char *arr[] = { "stuff", "here" };
<dramforever[m]1> this works
<ConanKudo[m]1> I really wish we had a version of Python subprocess for C
<ConanKudo[m]1> that and argparse
<dramforever[m]1> so i still think there is no justifiable reason for execv* to take char **, but it is what it is
<ConanKudo[m]1> the standard C API is... poorly thought out
<navi> the reason is allowing mutable strings, if it took `const char **` you wouldn't be able to pass in `argv` that main gives you
<navi> it's not great
<navi> but the fix isn't as easy as just adding const, sadly
<dramforever[m]1> yes, that's... a problem, yes
<f_> at this point write Wayback in shell scripts /j
<navi> honestly wayback session could be a shell script (like startx is)
<navi> xwayback maybe, wayback-compositor nope obviously
<f_> But xinit isn't a shell script, is it?
<dramforever[m]1> waybash
<navi> actually xwayback can't because socketpair
<f_> tbh .. could just use regular startx/xinit in the future
<f_> I think wayback-session won't stay for long
<ConanKudo[m]1> yeah eventually we won't need it
<ConanKudo[m]1> once /usr/bin/X emulation is good enough for 0.1 release, we can drop wayback-session entirely
<f_> Actually if you really wanted you could use Xwayback with startx *now*
<navi> ^ agreed
<navi> xinit already has code to handle multiple X server binaires
<navi> binaries*
<ConanKudo[m]1> it has to, since it used to be that you had a different server binary for a different graphics adapter
<f_> ConanKudo[m]1: 1.0 you mean? I thought we were aiming for 'good enough' X compat for 1.0?
<ConanKudo[m]1> if we have all the options stubbed out for 0.1, we don't need wayback-session at all
<ConanKudo[m]1> they options don't have to do anything
<ConanKudo[m]1> they just have to exist
<ConanKudo[m]1> having them work is 1.0
<dramforever[m]1> xinit sets the windowpath, which is probably possible to parse from xwininfo
<dramforever[m]1> other than that i don't see anything that inherently can't just be a shell script
<navi> all Xwayland and Xserver flags should work atm
<f_> ConanKudo[m]1: Oh good points
<navi> which means we're lacking... Xorg specific ones?
<ConanKudo[m]1> yup
<ConanKudo[m]1> and I think some of the Xserver ones too
<navi> Xwayland says it supports all Xserver flags
<ConanKudo[m]1> the organization of options described in the man pages is kind of bad
<f_> if arg is unknown { print "unknown arg"; continue; } ?
<ConanKudo[m]1> the problem is that we pass through now to Xwayland
<ConanKudo[m]1> so we can't do that
<f_> oh,ye
<ConanKudo[m]1> that means there needs to be a list of unhandleable options
<navi> with !70 (or is it #70) it should be easy to filter out flags
<Wayback> !70 xwayback: simplify argument parsing and main body (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/70) [opened]
<navi> either add them to the argc loop that -help is at and shuffle argv/argc, or simply skip them in the loop before execv
<ConanKudo[m]1> yeah, either solution is fine, but something has to be done
<ConanKudo[m]1> e.g. no XDMCP is ever going to work, so those options need to be stubbed
<f_> I'll see if I can work on that maybe later
<navi> Xwayland accepts those flags (as they're for Xserver)
<navi> and seems to just ignore them (the xdmcp ones)
<navi> anything in Xwayland and Xserver should be good, and the ones missing are the Xorg ones
<navi> vtXX, -config (oof), -logfile
<navi> we'll have to parse Xorg config files, at least partially, and see what applies to wayback
<f_> OK I'll see what I can do
<Wayback> #14 Reimplement `/usr/bin/X` (https://gitlab.freedesktop.org/wayback/wayback/-/issues/14) [opened]
<dramforever[m]1> keyboard layout is probably going to be the biggest thing
<ConanKudo[m]1> err #44
<Wayback> #44 Criteria for an initial release (https://gitlab.freedesktop.org/wayback/wayback/-/work_items/44) [opened]
<dramforever[m]1> for config
<navi> keyboard config will need wayback-compositor support
<f_> ConanKudo[m]1: awesome, thank you!
<navi> wait, will it
<navi> maybe
<ConanKudo[m]1> yes it will
<f_> yep
<ConanKudo[m]1> xwayland responds to the host compositor's state of the world
<dramforever[m]1> just input in general is going to be a pain that needs to be handled
<dramforever[m]1> because we won't have xf86 stuff to save us
<f_> lol xfree86 remember that
<navi> if i client tries to change keyboard state at runtime, say, setxkbmap
<navi> what happens?
<ConanKudo[m]1> sadly yes
<ConanKudo[m]1> navi: it should be ignored
<ConanKudo[m]1> xwayland doesn't forward downward IIRC
<f_> yeah maybe just ignore for now
<f_> Maybe later on it can be plumbed somehow
<ConanKudo[m]1> I'm pretty sure that's what happens right now
<dramforever[m]1> some setxkbmap options seem to work
<ConanKudo[m]1> that's how it works on every other wayland compositor
<dramforever[m]1> others don't
<navi> that'd be a bit of an issue, ignoring it for now works, but eventually we'll need to send patches to Xwayland to do that
<dramforever[m]1> i have no idea what rhyme or reason there is
<f_> wI think I can change keyboard state in sway at runtime?
<f_> s/w//
<ConanKudo[m]1> Yes, it's possible and in Fedora's sway live environment, we use this with Anaconda
<navi> sway can do it, issue is clients will only talk to Xwayland
<ConanKudo[m]1> to allow anaconda to change the environment through updating the locale1 interface
<ConanKudo[m]1> that syncs to sway through a helper, and that propagates back up into Xwayland immediately too
<navi> if there were no runtime api, then it would be easy, parse the config and give that to wayback-compositor
<navi> runtime means xwayland support means probably a custom wayland protocol
<navi> a custom, priviledged protocol for input configuration sounds good even outside wayback tbh
<navi> in the ext- namespace or smth
<ConanKudo[m]1> maybe I should file my locale1 ticket I filed on other compositors on wayback too
<ConanKudo[m]1> it's kind of important to be able to respond to that runtime API
<navi> i don't think wayback should implement locale1 directly, because it's dbus
<dramforever[m]1> can we have a temporary solution that talks to wayback-compositor directly for stuff like these
<navi> but the ext- protocol would allow it to exist like the wlr xdg portal
<navi> e.g. a dbus program that proxies it over to wayland protocols
<dramforever[m]1> hmm, turns out i don't actually know what user of dynamic layout switching need
<dramforever[m]1> but being able to set stuff like setxkbmap or touchpad at all is an improvement over not being able to set them anywhere
<ConanKudo[m]1> navi: that is not a good enough answer, tbh
<navi> locale1 is a system service too, bleh
<ConanKudo[m]1> "because it's dbus" is not helpful or useful
<Wayback> @Conan_Kudo opened issue: #53 Implement support for listening and reconfiguring the keyboard settings from locale1 (https://gitlab.freedesktop.org/wayback/wayback/-/issues/53)
<navi> it is when wayback-compositor was split from xwayback exactly to be minimal
<ConanKudo[m]1> it was split to have a separation of concerns, not to be minimal
<ConanKudo[m]1> "minimal" is a nebulous, undefined thing
<navi> plus a priv. protocol for keyboard configuration plus independent dbus daemon would be useful for many other projects as well
<ConanKudo[m]1> at least in the past, most of the compositors have been uninterested in exposing that through a wayland protocol because it's a "system concern"
<ConanKudo[m]1> and remember that most of the wlr ecosystem doesn't do privilege control for protocols, which means that "privileged protocols" aren't a thing in practice
<ConanKudo[m]1> if a wayland protocol gets made, most likely it will be wayback-specific and be a private protocol
<ConanKudo[m]1> that said, I want to make this very clear: "because it's dbus" is not a valid reason for invalidating a solution
<ConanKudo[m]1> I do not care whether you think dbus is good or bad, it is our general purpose contemporary IPC
<ConanKudo[m]1> so leave your complaints about dbus at the door, please, because they are unhelpful and unrealistic
<navi> security-context is implemented in most compositors that implement "priviledged" protocols
<ConanKudo[m]1> they do fuck all unless you are running a flatpaked app
<ConanKudo[m]1> nobody in the wlr ecosystem uses it for anything else
<navi> leaving seat IO concerns to wayland is separation of the concerns
<Consolatis[m]1> if the goal is to set the actual xkb config (and not just cycle and show the layout in a given keymap) then some custom IPC / locale1 watcher / private wayland protocol is likely required for wayback-compositor
<ConanKudo[m]1> yes
<ConanKudo[m]1> wayback-compositor will need a mechanism to do this
<Consolatis[m]1> I don't know how this actually works in X11, I assume its just some property on the root window? if yes then an application watching/updating that property + watching/updating locale1 and then being able to tell wayback-compositor about the new settings should be everything that is required. I don't think there are any changes required for xwayland to make it work
<Wayback> @Conan_Kudo closed issue: #44 Criteria for an initial release (https://gitlab.freedesktop.org/wayback/wayback/-/work_items/44)
<ConanKudo[m]1> I have created the %"0.1" milestone
<ConanKudo[m]1> Consolatis: I'm not sure it's a property on the root window, input stuff is a little weird with X11, since it's driver centric
<axtlos> dramforever[m]1: setxkbmap works, it's only the caps lock part that doesn't work
<navi> why make a priviledged protocol instead of working for an ext- one? it doesn't matter which we do since we don't expose wayland to any client except internal ones, but doing a proper protocol would be better for the whole ecosystem
<dramforever[m]1> huh, how about layout
<axtlos> yes
<axtlos> as I said, setxkbmap works
<dramforever[m]1> nice
<dramforever[m]1> so i just hit the one thing that doesn't work apparently
<axtlos> yes
cow has joined #wayback
<Wayback> @Conan_Kudo merged merge request: !71 wayback-session: properly handle XWAYBACK_PATH (https://gitlab.freedesktop.org/wayback/wayback/-/merge_requests/71)
<ConanKudo[m]1> navi: even if you made an ext- protocol, it would be privielged
<ConanKudo[m]1> *privileged
<ConanKudo[m]1> nobody will accept a proposal for this to be an unprivileged protocol
<ConanKudo[m]1> it's too dangerous
<navi> yea
<navi> i know
<navi> but we have ext-image-copy now, we do have priviledged protocols that can be used to implement out-of-wayland interfaces that need seat-IO
<ConanKudo[m]1> in general, I think the belief by compositor developers is that manipulating this through the display protocol was a mistake that shouldn't be repeated
<navi> we're also getting ext-virtual-keyboard
<ConanKudo[m]1> yes, but none of those are about changing the system
<ConanKudo[m]1> they are effectively plugs to existing state, not changing the way the system works
<ConanKudo[m]1> exposing a way to change xkb through w-p is something that I suspect would garner basically no support because you are creating a protocol to change runtime state of the compositor itself
<ConanKudo[m]1> keep in mind that not even output-management is an ext protocol in part because of poor design but also because philosophy around this
<ConanKudo[m]1> * poor design of the wlr protocol but also
<ConanKudo[m]1> admittedly there's been some talk about a global shortcuts protocol, which would be the first protocol proposed that changes compositor state
<ConanKudo[m]1> nothing has emerged yet though
<cow> Regardless, what's the problem with a protocol changing compositor state?
<cow> I'm not sure I follow here
<navi> i'm the one developing that protocol currently
<navi> i just didn't have any time for wayland-protocols in a while
<navi> action-binder / global-shortcuts is more like registering a callback with the compositor though
<cow> ConanKudo[m]1: If the compositor implements locale1, then wouldn't well, locale1 be the thing changing compositor state? i.e. the compositor state is still changed via a "protocol" of some kind regardless
<ConanKudo[m]1> yes, but locale1 is already the representative of the system state, the compositor is responding to it
<navi> ConanKudo[m]1: also doesn't ext-foreign-toplevel-management count as "client changing compositor state"?
<navi> or, runtime state
<navi> that one is also in the works
<ConanKudo[m]1> it is proposed but it hasn't gone anywhere in a while
joast has joined #wayback
<ConanKudo[m]1> action-binder is a similar "bind"
<ConanKudo[m]1> color-management might be your best argument about this
<ConanKudo[m]1> but neither toplevel-management nor color-management do persistent changes
<navi> a lot of protocols don't go anywhere in a while bc well, people already complained enough about that bit
<navi> also i'm not saying that the input config protocol would be persistent
<navi> it would be runtime, akin to setxkbmap
<ConanKudo[m]1> aside from X11 compatibility, what is the value of this?
<ConanKudo[m]1> because there's got to be a broader use-case to make it work
<navi> allow a client to be a configuration manager for seat things without out-of-band protocols
<navi> something like xfce's settings thing
<navi> which is a thing i'll need for my compositor as well
<navi> said client can have it's own configuration, and apply them on startup
<ConanKudo[m]1> I'm not sure how I feel about that
<ConanKudo[m]1> my gut feeling is "that's a bad idea"
<ConanKudo[m]1> in general, seat management is supposed to live somewhat outside the compositor
<ConanKudo[m]1> so "seat management things" as wayland protocols doesn't make sense to me
<ConanKudo[m]1> I may not be that much of a fan of seatd and libseat, but at least it does the thing as expected
<ConanKudo[m]1> and it offers compatibility with the existing external seat APIs
<Consolatis[m]1> heh, reads like s/#wayback/#wayland/ in here
<Consolatis[m]1> ext-workspace is btw another example of a protocol changing compositor state
<navi> by view is that wayland is used for seat io, taking inputs from keyboard/mouse/gamepad/tablet, processing that and passing to applications, then taking application's buffers and compositing as output for the user
<navi> thus, letting trusted programs interact with the running state makes more sense than using an out-of-band ipc that every single compositor wanting to support external configuration would need to implement
<navi> libseat is not about configuration though? it's about access, any configuration of keybinds or outputs is inherently in the compositor's realm
<navi> there's things that do not fit wayland
<navi> xrdb aka random resources for clients, do not
<ConanKudo[m]1> Consolatis: ext-workspace does not make persistent changes on its own, but you're right, it can be used that way
<navi> but i do think trusted clients managing the runtime state of compositors that allow it, in a manner that is cross-compatible in the ecosystem, is good imo
<ConanKudo[m]1> and yes it would read like that because I do wayland stuff and am very familiar with the various opinions of the different w-p stakeholders
<Consolatis[m]1> absolutely. ext-foreign + ext-foreign-interop with ext-workspace + action binder are an absolute requirement in my book
<ConanKudo[m]1> I don't think action-binder is going to make it
<navi> and thus i think output management and input management are too
<navi> ConanKudo[m]1: i want to re-design it now that i know a lot more about wayland
<ConanKudo[m]1> and I have no idea what ext-foreign-interop is
<navi> i think they mean interop of tools that interact with foreign toplevels
<Consolatis[m]1> interop between ext-foreign-toplevel-list-handle and ext-workspace
<navi> toplevel-handle was made an empty object exactly to do that
<ConanKudo[m]1> the budgie folks have their own wip proposal for global shortcut bindings that might also make it, the mir folks also working on something, etc.
<Consolatis[m]1> e.g. allowing a taskbar to filter by the active workspace
<Consolatis[m]1> or move windows to other workspaces
<navi> i do hate myself for letting action-binder fall out though
<navi> the design i had would even make it work without being priviledged at all
<ConanKudo[m]1> and that's a problem
<ConanKudo[m]1> nobody wants it to be workable unpriviileged
<ConanKudo[m]1> s/unpriviileged/unprivileged/
<ConanKudo[m]1> unprivileged access for all this stuff is a nightmare waiting to happen
<navi> the application would get a an proxy that triggers when their action triggers
<Consolatis[m]1> well, technically action binder would be fine unprivileged. its still up to the compositor to actually listen to those keys and send the respective events
<navi> no other information about it exists
<navi> it's as safe as getting any other input event
<ConanKudo[m]1> Consolatis: and it would
<ConanKudo[m]1> that's the problem
<Consolatis[m]1> why would it have to?
<ConanKudo[m]1> because people expect it to and thus it would
<navi> expect it to what?
<ConanKudo[m]1> reality is as soon as a capability is used it is expected to work, you can't really defy that without consequences
<ConanKudo[m]1> that's a big part of why the nitpicking goes on in w-p
<Consolatis[m]1> well, the whole privileged / unprivileged separation doesn't really matter to me. I just want to provide users with the options to use global shortcuts and being able to control them via user config. if some desktop portal impl which uses action binder to talk to the compositor is the way the ecosystem has settled on I am fine with that
<navi> action-binder would give the client just as much info of the event as the global portal does, if not less
<navi> it's like saying the global keybind portal is bad because clients would expect the shortcut they feed into it to be unconditionally accepted and matched
<ConanKudo[m]1> that isn't how the global shortcuts portal works
<ConanKudo[m]1> applications don't get to know what shortcut keybind was registered
<navi> but they do get to give a hint/ask/a suggestion
<ConanKudo[m]1> nope
<ConanKudo[m]1> they get a signal from the compositor that the action needs to fire
<navi> > preferred_trigger (s) - The preferred shortcut trigger, defined as described by the shortcuts XDG specification. Optional.
<navi> they, do
<cow> Also, action-binder makes it more accessible for other mechanisms to implement access control
<ConanKudo[m]1> technically, I guess that means they don't even need to know it was fired from a keybind
<cow> xdp only really supports Flatpak and Snap well right now, it's a non-trivial thing to get greater support, and as far as I can tell it would be fine for the portal to build off action-binder
<ConanKudo[m]1> sure
<navi> the xdg portal even gives back a human readable string of what triggers the shortcut
<navi> so it takes a "preferred combo", and gives out what got bound so the client can print out
<navi> sure, the preferred combo can be ignored, changed, and so on, but the exact same is true for action-binder
<ConanKudo[m]1> which honestly is a bit weird to me since the whole point of the portal interface is that the application can't do that
<ConanKudo[m]1> the portal system is supposed to use system UIs for that
<cow> What's wrong with providing a hint?
<cow> The system UI could "default" to using that as a keyboard shortcut unless set otherwise
<cow> It's a useful thing, the field is optional, I think the usecase is clear, and I'm not seeing how action-binder lacks here
<cow> action-binder has the advantage of being portable beyond xdp, and the interfaces seem similar enough
<navi> the interface for action-binder is more flexible, but it keeps the same promises as xdp
<cow> ^
<cow> This just sounds like let's use xdp because it's xdp
<cow> If I as a sandbox author or a compositor developer want to go about restricting access in my own way, action-binder provides that flexibility
<cow> Which notably portals can build off
<navi> more flexible because it's actually aware of wayland input methods for the "preferred keybind"
<ConanKudo[m]1> no, it's because dbus is easier to mediate than wl
<ConanKudo[m]1> right now, there are no generic mediation mechanisms for wayland IPC
<Ariadne> what does this have to do with wayback ?
<cow> security-context-v1?
<ConanKudo[m]1> Ariadne: this stemmed from the fact we don't have a way to handle runtime keyboard layout configuration and something needs to exist at the compositor level for that
<navi> Ariadne: it started as "how should wayback manage locale1", where i was in favor of coming up with an ext- protocol with an external client for dbus, instead of putting dbus directly in wayback-compositor
<Ariadne> i think our best odds of success with that is something custom that sits between wayback and xwayland
<ConanKudo[m]1> cow: I already said security-context doesn't work
<Ariadne> navi: yes, i do not want d-bus in the compositor
<cow> ConanKudo[m]1: okay, and regardless as mentioned compositors can do their own forms of access control
<ConanKudo[m]1> cow: sure, and almost all but mir and gnome/kde don't do any
<ConanKudo[m]1> yes I know
<Ariadne> dbus is a no-go
<ConanKudo[m]1> a similar proposal was made for kwin
<cow> (by me :P)
<ConanKudo[m]1> yes I know that too :)
<ConanKudo[m]1> Ariadne: do you have a reason other than "don't like dbus"?
<Ariadne> ConanKudo[m]1: yes. we are providing an "X server", not a desktop environment. dbus is not appropriate here
<cow> But, that still doesn't negate the usecase for action-binder though, gnome and kde can simply restrict access to the protocol to the portal I would presume, which works for everyone, whereas xdp limits what everyone can do with zero clear advantages; gnome and kde which use xdp can restrict access to just the portal, and everyone else can do their own thing built off action-binder :)
<ConanKudo[m]1> to be clear, I don't care if it's in wayback-compositor process or out of process, but something has to handle this
<cow> But, I think Ariadne has settled it
* ConanKudo[m]1 shrugs
<ConanKudo[m]1> responding to locale1 does need to be handled somehow
<Ariadne> does x.org respond to locale1?
<ConanKudo[m]1> it can, yes
<ConanKudo[m]1> just not directly
<cow> What component is responsible for responding?
<Ariadne> that isn't in x.org
<Ariadne> that's some fedora thing
<cow> + how would wayback respond to setxkbmap being called
<cow> This implies locale1_x11_sync would break in the first place
<ConanKudo[m]1> yes it does
<ConanKudo[m]1> because it does
<navi> we have to make setxkbmap work with wayback
<cow> ^
<navi> and if we do that, then that sync tool works as is
<cow> That is also the "xorg standard" persay
<ConanKudo[m]1> sure
<Ariadne> anything in wayback depending on dbus is most likely entirely wrong
<ConanKudo[m]1> Ariadne: I also disagree with your assessment that dbus is "desktop environment" only
<ConanKudo[m]1> it hasn't been that way for more than a decade
<Ariadne> if you say so
<cow> I think regardless Ariadne has a good point regardless of what people think of dbus, the point is to support the old Xorg ecosystem of tools
<navi> (that's not how dbus behaves, a lot of the --session tools expect the structure that a DE gives, i've seen that first hand a lot while developing openrc --user)
<cow> Replacing them with support for dbus apis that Xorg doesn't respond to doesn't make sense
<navi> anyway, make setxkbmap work, then all is good
<Ariadne> in my experience, outside of desktop linux, dbus is one IPC mechanism of several
<cow> Not to speak for Ariadne (please correct me if I'm wrong), but my understanding is that DBus is out of scope for wayback because it's out of scope for Xorg
<cow> And the point is to support *Xorg* apis
<Ariadne> yes
<Consolatis[m]1> all of this is pretty irrelevant for this specific case. The point seems not about watching locale1 but about figuring out how to a) get a signal when setxkbmap is called and b) how to tell wayback-compositor about it so it can create a new xkb-state internally and automatically update xwayland
<ConanKudo[m]1> that will probably require changes to xwayland
<Consolatis[m]1> I am not yet convinced about that
<Ariadne> it may require changes to both wayback and xwayland. that's always been part of the deal, though
<Consolatis[m]1> what does setxkbmap actually do?
<ConanKudo[m]1> because below wb-comp is below xwayland and can't see what gets written to xwl and not propagated downward
<Ariadne> at no time has any assertion been made that xwayland will be suitable as a full solution without modifications
<ConanKudo[m]1> yeah that was always a given
<Ariadne> streamlining that process, in fact, was the reason the project got moved to freedesktop.org... so these modifications regardless of where they need to be done can be tracked in one location
<cow> And this while this Fedora specific requirement would work if we implement locale1 in wayback, what about for everyone else with their own soloutions (not neccessarily related to locale1) dependening on setxkbmap
<navi> if it does require xwayland changed, then it'll need a way to propagate up the change to the compositor via the wl socket, then a protocol we can upstream to them
<ConanKudo[m]1> we already know at least for output connections needs extensions to xwayland
<cow> navi: That sounds reasonable
<Ariadne> but nonetheless, wayback should be "shaped" similarly to the standalone x.org server
<Ariadne> and at least in alpine, x.org does not depend on dbus
<navi> Xwayback is getting there
<navi> being in fdo will make it easier to get it onto xinit's list asl
<navi> asw*
<Consolatis[m]1> there are cases where xwayland has to be modified, like it could emulate redshift via wlr-gamma-control-unstable-v1 for example, just not convinced that setxkbmap also requires that. guess I'll just read its sources to figure out what it actually does
<Ariadne> now i need to finish wrapping up my fractional CTO gig so i can go camping this weekend :p
<navi> setxkbmap seems to 90% functional
<navi> just some things around capslock seems to fail
<navi> (going by logs in this chat earlier today)
<Consolatis[m]1> that sounds like the XKB_OPTIONS are not set
<Consolatis[m]1> e.g. the XKB_DEFAULT_OPTIONS env var
<navi> to change the options at runtime, it would need to reach the compositor's internal xkb state, no?