ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Leopold___ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
softmoth has joined #wayland
ciara has quit [Read error: No route to host]
ciara has joined #wayland
fmuellner_ has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Ping timeout: 480 seconds]
<softmoth>
Does the registry contain info on what object is focused by the compositor? or would I need to query sway (for example) directly to get focus info? I'm wanting to get (or maintain) a least recently used access list of client windows.
Dami_Lu has quit [Remote host closed the connection]
<jadahl>
emersion: for the latter, apparently 2/3 of the members need to ack. daniels me and I guess implicitly you have already. what % does that make up for?
iomari892 has quit [Remote host closed the connection]
Max1 has joined #wayland
orowith2os has joined #wayland
<orowith2os>
emersion question for the seat protocol, does that (and friends) provide a benefit over something like libei? I don't really get why you'd want that over libei, since we have the latter now.
<orowith2os>
just poking around so I understand it all better :P
iomari891 has joined #wayland
<emersion>
i do not wish to support libei in my compositor
<emersion>
wayland protocols are simpler
<emersion>
jadahl: 2/6
<emersion>
maybe should vote to drop inactive members… like EFL
<emersion>
or maybe should just reinstate wlr-protocols as my latest comment suggests
<pq>
The wording in wl_registry.global_remove about "ignored" seems like a bug to me. Requests cannot generally be ignored. Either they "work", or a protocol error disconnects the client.
<emersion>
right, i think the intended meaning was "inert"
leandrohrb56 has joined #wayland
<pq>
That wording was written in 2012, I'm not sure the concept of inert had even been invented yet.
<pq>
but I believe it was incorrect already then
<pq>
jadahl, looks like there are 8 members listed. 2/3rds would need 6 acks I believe.
crazybyte has quit [Quit: Ping timeout (120 seconds)]
<any1>
emersion: Thanks for pushing transient-seat.
<any1>
It's a short and simple protocol. Takes around 5 minutes to read through and understand. Although it might not be immediately useful to everyone's needs, it does fill a gap in the core protocol.
<orowith2os>
I'm just a bit worried with some fragmentation over the protocol and libei, though I wonder if the two could be bridged a bit to mitigate that, so that libei users work with the protocols. Would be nice.
<any1>
What does libei have to do with it?
<orowith2os>
they seem related, with letting applications generate input events
<orowith2os>
think stuff like Synergy/Barrier
<orowith2os>
or remote desktop software
<orowith2os>
you have the wayland protocol, and libei, both of which can achieve the same (or similar?) end result
<emersion>
same situation with pipewire
<any1>
Well, I guess that's one way to interact with wayland: just skip w-p altogeather and plug your lib straight into the compositor.
Dami_Lu has quit [Remote host closed the connection]
<orowith2os>
just seems a bit weird to me, is all. In the end, they'l probably end up achieving different things for different people, with the wp more for WM stuff and xdp+libei for DEs, I guess?
<any1>
Isn't this just a false dichotomy?
<orowith2os>
Will admit that I'm not completely knowledgeable on this, I'm only just barely getting started into writing a mini compositor with Smithay after all. Just trying to make sense of it now, in the hopes I can build it up after a while.
<orowith2os>
Maybe?
<orowith2os>
if you can make it more clear on where the two are supposed to be used, that would be appreciated
<emersion>
for wlroots, wayland protocols are "native", and D-Bus/xdg-desktop-portal/PipeWire/libei is a compat layer
bookworm has quit []
<any1>
same for wayvnc, except we only support wayland protocols.
<any1>
Well, there will be pipewire for audio capturing at some point, but that's firmly outside of wayland's domain.
<orowith2os>
from what emersion said, and pairing it with how the wlroots portal works... I guess it would end up being that libei would get sent stuff from the protocol to work with xdp users?
<orowith2os>
Do I have that right?
<orowith2os>
or is that (pipewire screencap) a different situation?
<emersion>
yeah. pipewire is the same
<orowith2os>
okayy, that makes a lot more sense now
<orowith2os>
so there's not really any "fragmentation" here, at least not too much. Everything else (portals) will still work, but compositor-specific solutions (wayvnc) will work how they prefer, and only worry about their intended environments?
<orowith2os>
(aka no debugging wayvnc or xdp-wlr on KDE or GNOME, only wlroots compositors)
<any1>
wayvnc will work with whichever compositor that implements the required protocols
<orowith2os>
you get what I mean
<orowith2os>
less envs to test and find bugs with
cmichael has joined #wayland
Dami_Lu has joined #wayland
<orowith2os>
unless there's some other reason, or just preference for APIs to interact with
<any1>
No, I'm not really sure where you're going with this.
<orowith2os>
...probably the latter. Well, I just wasted typing all of that out.
<orowith2os>
it's late, I'm tired, and I'm most definitely looking too far into this >>
<orowith2os>
just gonna leave this be
<psykose>
bed time
<orowith2os>
just a little mirmir :)
<orowith2os>
mrmir
<orowith2os>
mimir
<orowith2os>
dammit
<orowith2os>
yeah, I'm logging off for the night
bookworm has joined #wayland
<any1>
I'll phrase this in a simple good vs. evil context: There are rebels who can't be bothered with going through the incumbent w-p and they seem to be winning. We, the incumbents, are losing, probably because there is too much gatekeeping going on in w-p.
<any1>
Worries about fragmentation only serve the rebels becaues they move faster and implement more things in shorter time.
pochu has joined #wayland
cmichael has quit [Remote host closed the connection]
cmichael has joined #wayland
cmichael has quit []
Major_Biscuit has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
<MrCooper>
any1: that's pretty inflammatory; the reason for things like libei not being a Wayland protocol is that they are considered out of scope for a Wayland protocol, not to bypass the wayland-protocols rules
<pq>
Personally I don't like using Wayland extensions for things that are not regular applications, but I still do it with Weston private extensions, because it's easy and familiar, and not because it would somehow be The Right Thing. Of course, sometimes using a Wayland extension is warranted because tje topic is inherently related to windows, like touchscreen calibration extension need to display a special
<pq>
window.
<pq>
I'd love to have a not-Wayland RPC interface to Weston, but meh, have more important things to do.
<daniels>
pq: looks like os_wrappers_dupfd_cloexec fails on fbsd sometimes
<any1>
MrCooper: Sorry, wasn't meant to be taken seriously.
<MrCooper>
k, then I'm honestly glad
<pq>
I did not see it as a joke at all.
<any1>
The message at the core was no joke: Worries about fragmentatin stifle innovation and development. We shouldn't rule things out because they've already been implemented elsewhere or because 1 or 2 people think that they should be implemented elsewhere.
<any1>
err, fragmentation rather
<any1>
and also, w-p is slowed down by gatekeeping.
<any1>
And things that bypass w-p altogeather are a symptom of that problem.
<ifreund>
a more concrete and scary example is Hyperland shipping unmerged w-p proposals by default (ext-workspace)
<ifreund>
which Waybar now ships as well iirc
<pq>
any1, that is why I don't send NAKs to wayland-protocols.
fmuellner has joined #wayland
<pq>
nor would I have time to look into most things anyway
<any1>
pq: Well, currently, in the ext- namespace inaction has the same end result as negative action.
<daniels>
sure, but none of it is getting gatekept by people saying 'this has no right to be in w-p'
<daniels>
it's getting bikeshedded by people who want vaguely the same thing but can't agree on what that thing is
<pq>
Things that "bypass w-p" are not a symptom of anything, if the developers of the thing deemed it to be out of scope for Wayland. They wouldn't submit to w-p even if there was no gatekeeping.
<daniels>
I try to help out and steer the protocols that I'm interested in, but as someone who doesn't believe that e.g. client-driven window management should be a part of the protocol, I'm not the right person to help decide on what client-driven window management should look like within the protocol
<ifreund>
In my experience, the bikeshedding does help us arrive at simpler, more useful protocols
<ifreund>
designing a high quality wayland protocol is really not that easy
<any1>
Why should there not be "client-driven window management" protocols?
<any1>
They are clearly needed, why must they go a different route than other wayland protocols?
<ifreund>
I think the real limiting factor is not gatekeeping or bikeshedding but rather interested and capable reviewer having time
<MrCooper>
any1: adding a simple Wayland protocol which lets clients control something which affects other clients is surely simpler and quicker than doing something like libei, which has been a multi-year effort, so that doesn't make too much sense either
<pq>
Are they needed? I'm not convinced. They may be needed *after* one has committed to a specific system architecture.
<MrCooper>
to me, it's repeating a big mistake from X
<ifreund>
If we had some actual access control system for protocol access it'd seem more attractive to me
<any1>
pq: So you would say that things like Xvnc should not exist for wayland?
<pq>
I don't know what actual benefits externalizing window management would have.
<pq>
any1, that's not remote window management.
<pq>
remote window management is like all X11 window managers that run in a separate process from Xorg
<any1>
pq: Is ext-transient-seat remote window management?
<pq>
I don't remember anything of it.
<ifreund>
ext-workspace would be an example
<ifreund>
same with ext-foreign-toplevel-management
<ifreund>
they're both somewhat limited compared to an X11 wm of course, but they allow clients to affect the window management of other clients
<any1>
Ah, I see.
<any1>
Those seem useful, at least, although perhaps not essential
<daniels>
any1: if it was 'clearly needed', I wouldn't be saying that I didn't think it should be in the protocol :)
<any1>
daniels: Yeah, I was confused about the meaning of "client-driven window management"
co1umbarius has joined #wayland
<any1>
Protocols like screencopy and virtual inputs are not protocols that are needed by "traditional" clients. What are your views on those?
<any1>
pq, daniels: ^
columbarius has quit [Ping timeout: 480 seconds]
<ifreund>
I think they would be a no-brainer if we had proper protocol-level access control
<ifreund>
we don't though, so it seems like a valid stance to me to use a side-channel that does
<ifreund>
I personally implement them in my compositor with the view that anything proprietary or potentially malicious should be sandboxed anyway
<daniels>
right, and there are enough different viewpoints on how that should actually mechanically work that I'm not sure it's possible to express 'security' and access control as a common protocol, though I'm happy to be surprised
<ifreund>
and there is hope for wayland-protocol access control for sandboxed programs
<daniels>
screencopy already has protocols and I personally prefer that as an OOB mechanism
<daniels>
*portals
navi has joined #wayland
<any1>
My personal opinion is that desktop protal just adds a layer of complexity that I'm not really willing to deal with. With wayland protocols there is a minimal amount of crud in between.
kts has joined #wayland
<any1>
Makes things much simpler to debug and allows for more optimisation
<daniels>
I disagree, but that's ok, it's subjective
<any1>
wayland portal adds more code in between. It is objectively more complex on the whole. :)
<pq>
You could ask, why were portals invented to begin with? What problem are they solving? If that problem will never be your problem, good for you.
<any1>
err, desktop portal rather
<pq>
people don't usually over-engineer from the start as most prefer simplicity like you do
<emersion>
yeah, i agree with any1 here on complexity of portals/pipewire/etc, but to each their own
<navi>
You could ask, why were portals invented to begin with? -- for xdg-desktop-portals it was to selectively breach flatpak's sandbox
<daniels>
any1: complexity isn't just a function of LoC. it's the semantics and the implications of those lines of code. you can make a system less complex by introducing more code but in a way which makes it far more clear and robust.
<any1>
pq: If I understand correctly, they're trying to make things more "secure", but I never understood why they didnt't try to do that through w-p. However, I now understand that there are people who actually think that not all things should go through wayland protocols, as I do.
<any1>
daniels: Yes, if you believe that blackboxes are always perfect and never need to be debugged.
<emersion>
more moving pieces…
<emersion>
also pipewire isn't exactly what i'd call "simple"
<navi>
i'm still one to think that the two biggest things portals do on wayland, screen sharing and keybinds, would be nice to have as w-p
ahartmetz has joined #wayland
<orowith2os>
the largest issue there is user interaction :p
<navi>
leave that to the compositor :3
<orowith2os>
you want screensharing and portals to involve the user controlling what goes on, which would involve Wayland extending its reach to a permission-based system
<dottedmag>
orowith2os: Another thing to consider when thinking lib/protocol is non-C compositors. Bringing and bridging yet another C library is always a pain.
<navi>
orowith2os: just let each compositor deal with how it wants to allow permissions for that, no?
<orowith2os>
cont from my last: something Portals were designed to do, and Wayland is more... something that happens in the background
<orowith2os>
You'd need Wayland to set up something like PipeWire has for passing FDs to clients through remotes, I believe
<orowith2os>
you probably can't go through the socket?
<orowith2os>
so it's possible with Wayland, but you'd probably need to take a bit of inspiration from PW
<orowith2os>
and would mean the traditional Wayland socket is inaccessible, otherwise everything can access privileged protocols
<orowith2os>
if I'm understanding this all correctly, ofc
<orowith2os>
or just have two sockets: one privileged, one unprivileged
<orowith2os>
IMO it's all adding too much complexity, portals and more dedicated libraries handle it better
<orowith2os>
you want to capture the screen, go through a portal for user interaction and get access to a PipeWire remote for that, which it was made in mind with.
<orowith2os>
emulate some input? same thing, but access libei
<orowith2os>
or restart the universe and redesign everything.. again :)
<emersion>
there's no need for that
kts has quit [Quit: Konversation terminated!]
<emersion>
you can allow/deny what wayland clients can do
<orowith2os>
how is that filter managed?
<emersion>
either you hide globals, either you make protocol requests fail
<navi>
if the issue is still user interaction, the protocol only defines how to ask the compositor, when asked the compositor decides, it could show a popup, just check a config option, or just allow it regardless. and if now allowed, fail the request and return an error
<orowith2os>
with Flatpak, you have a sandbox around apps to tell which ones get access to which resources, and the portals can allow or deny whatever. It's more complicated to get something like that going with something like Wayland where communication all goes over one socket, AFAICT?
<orowith2os>
hm
<navi>
the w-p doesn't need to care about *how* the auth works, just if it succeeds or fails
<navi>
that's what i think at least
<orowith2os>
what about clients which should get immediate and unrestricted access to all resources, like a split shell-compositor thing like KDE has?
<orowith2os>
you don't want a permission dialog showing up asking if you want your shell to function, after all
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
<orowith2os>
but you also don't want arbitrary clients hijacking that, which is an issue with, for example, unsandboxed PipeWire
<navi>
i was thinking of protocols for screensharing and global keybinds, what resources would this shell need?
<orowith2os>
I want to say "basically everything"
<orowith2os>
especially if you want to tightly integrate the shell with the compositor
<orowith2os>
taking a peek at all of the KDE protocols on https://wayland.app might be a good reference
<navi>
considering that the compositor would handle if a request succees or fails, the simples thing i can think of is just the compositor keeping a allow list for the resources that includes it's own shell
<navi>
i'll look at those then
<navi>
for a gui shell, there's also layer shell
<orowith2os>
for a short list: blur, emulated input, user idle time, output management/devices, the shell, virtual desktops, window management, and screencast
<orowith2os>
well, that's basically everything, not a short list...
<orowith2os>
also random bit, but might I mention that KDE uses PipeWire in their shell too? Whenever you hover over an app icon and get a preview, that uses PW :D
<navi>
for the plasma shell, there's also, well, KDE plasma shell
Ryzen has joined #wayland
cmichael has joined #wayland
Leopold__ has joined #wayland
softmoth has joined #wayland
Ryzen has left #wayland [Leaving]
Leopold_ has quit [Ping timeout: 480 seconds]
<zzag>
we plan to kill the plasma shell protocol. plasmashell already uses the layer-shell protocol for some of the things, e.g. splash screen, logout greeter, and panel+background in master
<navi>
imo using layer-shell makes sense, having less protocols to do the same thing sounds nice
jmdaemon has quit [Ping timeout: 480 seconds]
JoshuaAs- has quit []
JoshuaAshton has joined #wayland
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<kennylevinsen>
if only kdbus had worked out an become a proper, in-kernel IPC system...
fmuellner_ has joined #wayland
<navi>
considering that like more than half of the issues with me trying to get user script/services to work on openrc came from dbus-daemon
<navi>
kdbus would've been so nice
<psykose>
every time i see kdbus i think of kde dbus
<MrCooper>
that was called DCOP ;)
<kennylevinsen>
navi: I do find dbus-broker a bit nicer to work with
fmuellner has quit [Ping timeout: 480 seconds]
<navi>
the main pain point was for writing the user script for dbus-daemon --session, i had to come up with a system where init scripts in openrc could export variables for *other* scripts, so that DBUS_SESSION_BUS_ADDRESS would be set right, then modify openrc-pam to load those vars for the user session (but only the ones allowed by the sysadmin ones because seems like letting users define
<navi>
any env in pam is a bad idea)
<navi>
in the end it came out as a nice system that can be used fo other stuff too tho, like ssh-agent