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
<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?
<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
<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
<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>
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
<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
<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>
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?
<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?
<Consolatis[m]1>
yes, likely
<navi>
i can see how it could translate the keymap by itself
<navi>
but options will require a protocol to propagate up
<Consolatis[m]1>
that kind of depends on what actually happens when setxkbmap is called
<navi>
yeah
<navi>
i'm speculating mostly
<Ariadne>
this is likely to be a private extension between wayback and xwayland is my guess
<cow>
Ariadne: Why private?
<Ariadne>
i envision an extension that allows a wayland client to push new keyboard state to the compositor
<Ariadne>
that seems... unaligned with upstream wayland's security philosophy
<navi>
that was part of the debate here, i argued that having that extension as a priviledged ext- namespaced protocol would be helfull for the ecosystem
<cow>
^
<cow>
Ariadne: Possibly could get it in ext maybe, I think there has been a shift to include more privileged protocols now
<navi>
it's not far from other extensions that modify compositor state, that already exist
<cow>
(ofc access control can be done via other methods)
<Ariadne>
i mean, we can try to get it in ext, but
<Ariadne>
our priority is just to make the thing work. it does not really matter where the xml file lives :p
<navi>
making it work is kind of a requirement for proposing anyway
<navi>
having implementations, we'd just be a implementation
<Consolatis[m]1>
hm.. isn't this just a root window property?
<navi>
if it's all root window, then we can have an x initfd client
<navi>
that listen for evens in the root window, and passes it to wayback via $protocol
<Consolatis[m]1>
yep
<Consolatis[m]1>
or pipe or whatever
<Consolatis[m]1>
I mean just to confirm its nothing specific to my setup, tested with setxkbmap -layout us,de -option grp:win_space_toggle and then did xprop -root
<navi>
though my only worry now is, since keymapping already works, xwayland is probably doing some translation
<navi>
if we can change the mapping in wayback itself, ideally we'd disable that translation and handle it all on our own, i think?
<Consolatis[m]1>
i am not sure how the key input part of xwayland works. might be fine as long as they are synced. also not sure how switching layouts from the X11 side works in this case, in wayland the "group" keyboard modifier defines the active layout within the keymap and thus might overwrite a layout set internally by X11
<Consolatis[m]1>
so one would likely as need a X11 signal about the layout being changed. that sounds doable via the same xcb client that listens to the property changed signal of the root window though