02:29softmoth: 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.
02:52RAOF: softmoth: In general, clients can get *no* information about any other client from the compositor. If your compositor implements https://wayland.app/protocols/wlr-foreign-toplevel-management-unstable-v1 (and lets you use it) you could use that to mantain an LRU focus list.
02:56softmoth: Thanks, RAOF!
07:07wlb: wayland Issue #236 closed \o/ (Bump Wayland Meson dependency version https://gitlab.freedesktop.org/wayland/wayland/-/issues/236)
07:15wlb: wayland Merge request !323 opened by Simon Ser (emersion) Add missing tests https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/323 [Testing]
07:17wlb: wayland Issue #272 closed \o/ (Meson Deprecation Warning + AMD AOCC (Clang 13.0.0 cc compiler) + Ninja Warnings https://gitlab.freedesktop.org/wayland/wayland/-/issues/272)
07:48emersion: ping for ACKs on https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/61
07:52emersion: also related is https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/192
07:54jadahl: 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?
07:56orowith2os: 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.
07:57orowith2os: just poking around so I understand it all better :P
08:03emersion: i do not wish to support libei in my compositor
08:04emersion: wayland protocols are simpler
08:05emersion: jadahl: 2/6
08:06emersion: maybe should vote to drop inactive members… like EFL
08:07emersion: or maybe should just reinstate wlr-protocols as my latest comment suggests
08:09pq: 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.
08:11emersion: right, i think the intended meaning was "inert"
08:21pq: That wording was written in 2012, I'm not sure the concept of inert had even been invented yet.
08:23pq: but I believe it was incorrect already then
08:26pq: jadahl, looks like there are 8 members listed. 2/3rds would need 6 acks I believe.
08:42wlb: wayland/main: Simon Ser * tests: add missing proxy-test https://gitlab.freedesktop.org/wayland/wayland/commit/f181de1bcf7d tests/meson.build
08:42wlb: wayland/main: Simon Ser * egl: add missing ABI check test https://gitlab.freedesktop.org/wayland/wayland/commit/4a7348e48c05 egl/meson.build
08:42wlb: wayland Issue #167 closed \o/ (Meson runs 23 tests while autotools runs 25, is something missing? https://gitlab.freedesktop.org/wayland/wayland/-/issues/167)
08:42wlb: wayland Merge request !323 merged \o/ (Add missing tests https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/323)
08:46pq: ah, uh, post-merge CI failed on FreeBSD in os-wrappers-test
08:50emersion: and succeeded after restart?
08:52pq: yes, it seems so
08:52pq: https://gitlab.freedesktop.org/wayland/wayland/-/jobs/44048693 failed, https://gitlab.freedesktop.org/wayland/wayland/-/jobs/44048884 succeeded with a simple retry
09:03any1: emersion: Thanks for pushing transient-seat.
09:11any1: 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.
09:14orowith2os: 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.
09:15any1: What does libei have to do with it?
09:16orowith2os: they seem related, with letting applications generate input events
09:16orowith2os: think stuff like Synergy/Barrier
09:17orowith2os: or remote desktop software
09:18orowith2os: you have the wayland protocol, and libei, both of which can achieve the same (or similar?) end result
09:19emersion: same situation with pipewire
09:19any1: Well, I guess that's one way to interact with wayland: just skip w-p altogeather and plug your lib straight into the compositor.
09:21orowith2os: 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?
09:22any1: Isn't this just a false dichotomy?
09:22orowith2os: 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.
09:23orowith2os: Maybe?
09:23orowith2os: if you can make it more clear on where the two are supposed to be used, that would be appreciated
09:24emersion: for wlroots, wayland protocols are "native", and D-Bus/xdg-desktop-portal/PipeWire/libei is a compat layer
09:24any1: same for wayvnc, except we only support wayland protocols.
09:25any1: Well, there will be pipewire for audio capturing at some point, but that's firmly outside of wayland's domain.
09:27orowith2os: 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?
09:27orowith2os: Do I have that right?
09:28orowith2os: or is that (pipewire screencap) a different situation?
09:28emersion: yeah. pipewire is the same
09:28orowith2os: okayy, that makes a lot more sense now
09:30orowith2os: 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?
09:30orowith2os: (aka no debugging wayvnc or xdp-wlr on KDE or GNOME, only wlroots compositors)
09:34any1: wayvnc will work with whichever compositor that implements the required protocols
09:34orowith2os: you get what I mean
09:34orowith2os: less envs to test and find bugs with
09:38orowith2os: unless there's some other reason, or just preference for APIs to interact with
09:38any1: No, I'm not really sure where you're going with this.
09:38orowith2os: ...probably the latter. Well, I just wasted typing all of that out.
09:39orowith2os: it's late, I'm tired, and I'm most definitely looking too far into this >>
09:39orowith2os: just gonna leave this be
09:42psykose: bed time
09:43orowith2os: just a little mirmir :)
09:43orowith2os: mrmir
09:43orowith2os: mimir
09:43orowith2os: dammit
09:43orowith2os: yeah, I'm logging off for the night
09:47any1: 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.
09:48any1: Worries about fragmentation only serve the rebels becaues they move faster and implement more things in shorter time.
10:03MrCooper: 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
10:12pq: 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
10:12pq: window.
10:13pq: I'd love to have a not-Wayland RPC interface to Weston, but meh, have more important things to do.
10:13daniels: pq: looks like os_wrappers_dupfd_cloexec fails on fbsd sometimes
10:19any1: MrCooper: Sorry, wasn't meant to be taken seriously.
10:20MrCooper: k, then I'm honestly glad
10:21pq: I did not see it as a joke at all.
10:28any1: 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.
10:29any1: err, fragmentation rather
10:31any1: and also, w-p is slowed down by gatekeeping.
10:31any1: And things that bypass w-p altogeather are a symptom of that problem.
10:33ifreund: a more concrete and scary example is Hyperland shipping unmerged w-p proposals by default (ext-workspace)
10:33ifreund: which Waybar now ships as well iirc
10:33pq: any1, that is why I don't send NAKs to wayland-protocols.
10:34pq: nor would I have time to look into most things anyway
10:36any1: pq: Well, currently, in the ext- namespace inaction has the same end result as negative action.
10:37daniels: sure, but none of it is getting gatekept by people saying 'this has no right to be in w-p'
10:37daniels: it's getting bikeshedded by people who want vaguely the same thing but can't agree on what that thing is
10:37pq: 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.
10:38daniels: 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
10:39ifreund: In my experience, the bikeshedding does help us arrive at simpler, more useful protocols
10:40ifreund: designing a high quality wayland protocol is really not that easy
10:40any1: Why should there not be "client-driven window management" protocols?
10:41any1: They are clearly needed, why must they go a different route than other wayland protocols?
10:41ifreund: I think the real limiting factor is not gatekeeping or bikeshedding but rather interested and capable reviewer having time
10:42MrCooper: 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
10:42pq: Are they needed? I'm not convinced. They may be needed *after* one has committed to a specific system architecture.
10:42MrCooper: to me, it's repeating a big mistake from X
10:43ifreund: If we had some actual access control system for protocol access it'd seem more attractive to me
10:43any1: pq: So you would say that things like Xvnc should not exist for wayland?
10:44pq: I don't know what actual benefits externalizing window management would have.
10:44pq: any1, that's not remote window management.
10:44pq: remote window management is like all X11 window managers that run in a separate process from Xorg
10:44any1: pq: Is ext-transient-seat remote window management?
10:45pq: I don't remember anything of it.
10:45ifreund: ext-workspace would be an example
10:46ifreund: same with ext-foreign-toplevel-management
10:47ifreund: they're both somewhat limited compared to an X11 wm of course, but they allow clients to affect the window management of other clients
10:48any1: Ah, I see.
10:48any1: Those seem useful, at least, although perhaps not essential
10:48daniels: any1: if it was 'clearly needed', I wouldn't be saying that I didn't think it should be in the protocol :)
10:49any1: daniels: Yeah, I was confused about the meaning of "client-driven window management"
10:51any1: Protocols like screencopy and virtual inputs are not protocols that are needed by "traditional" clients. What are your views on those?
10:52any1: pq, daniels: ^
10:54ifreund: I think they would be a no-brainer if we had proper protocol-level access control
10:55ifreund: we don't though, so it seems like a valid stance to me to use a side-channel that does
10:56ifreund: I personally implement them in my compositor with the view that anything proprietary or potentially malicious should be sandboxed anyway
10:56daniels: 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
10:56ifreund: and there is hope for wayland-protocol access control for sandboxed programs
10:56daniels: screencopy already has protocols and I personally prefer that as an OOB mechanism
10:56daniels: *portals
11:05any1: 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.
11:06any1: Makes things much simpler to debug and allows for more optimisation
11:06daniels: I disagree, but that's ok, it's subjective
11:07any1: wayland portal adds more code in between. It is objectively more complex on the whole. :)
11:07pq: 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.
11:07any1: err, desktop portal rather
11:08pq: people don't usually over-engineer from the start as most prefer simplicity like you do
11:08emersion: yeah, i agree with any1 here on complexity of portals/pipewire/etc, but to each their own
11:11navi: You could ask, why were portals invented to begin with? -- for xdg-desktop-portals it was to selectively breach flatpak's sandbox
11:12daniels: 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.
11:12any1: 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.
11:13any1: daniels: Yes, if you believe that blackboxes are always perfect and never need to be debugged.
11:13emersion: more moving pieces…
11:13emersion: also pipewire isn't exactly what i'd call "simple"
11:13navi: 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
11:16orowith2os: the largest issue there is user interaction :p
11:16navi: leave that to the compositor :3
11:16orowith2os: 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
11:17dottedmag: orowith2os: Another thing to consider when thinking lib/protocol is non-C compositors. Bringing and bridging yet another C library is always a pain.
11:17navi: orowith2os: just let each compositor deal with how it wants to allow permissions for that, no?
11:17orowith2os: cont from my last: something Portals were designed to do, and Wayland is more... something that happens in the background
11:18orowith2os: You'd need Wayland to set up something like PipeWire has for passing FDs to clients through remotes, I believe
11:18orowith2os: you probably can't go through the socket?
11:20orowith2os: so it's possible with Wayland, but you'd probably need to take a bit of inspiration from PW
11:21orowith2os: and would mean the traditional Wayland socket is inaccessible, otherwise everything can access privileged protocols
11:21orowith2os: if I'm understanding this all correctly, ofc
11:21orowith2os: or just have two sockets: one privileged, one unprivileged
11:22orowith2os: IMO it's all adding too much complexity, portals and more dedicated libraries handle it better
11:23orowith2os: 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.
11:23orowith2os: emulate some input? same thing, but access libei
11:24orowith2os: or restart the universe and redesign everything.. again :)
11:25emersion: there's no need for that
11:25emersion: you can allow/deny what wayland clients can do
11:26orowith2os: how is that filter managed?
11:26emersion: either you hide globals, either you make protocol requests fail
11:27navi: 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
11:27orowith2os: 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?
11:28orowith2os: hm
11:28navi: the w-p doesn't need to care about *how* the auth works, just if it succeeds or fails
11:28navi: that's what i think at least
11:29orowith2os: what about clients which should get immediate and unrestricted access to all resources, like a split shell-compositor thing like KDE has?
11:29orowith2os: you don't want a permission dialog showing up asking if you want your shell to function, after all
11:31orowith2os: but you also don't want arbitrary clients hijacking that, which is an issue with, for example, unsandboxed PipeWire
11:31navi: i was thinking of protocols for screensharing and global keybinds, what resources would this shell need?
11:36orowith2os: I want to say "basically everything"
11:36orowith2os: especially if you want to tightly integrate the shell with the compositor
11:38orowith2os: taking a peek at all of the KDE protocols on https://wayland.app might be a good reference
11:38navi: 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
11:38navi: i'll look at those then
11:39navi: for a gui shell, there's also layer shell
11:40orowith2os: for a short list: blur, emulated input, user idle time, output management/devices, the shell, virtual desktops, window management, and screencast
11:40orowith2os: well, that's basically everything, not a short list...
11:41orowith2os: 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
11:41navi: for the plasma shell, there's also, well, KDE plasma shell
12:28zzag: 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
12:31navi: imo using layer-shell makes sense, having less protocols to do the same thing sounds nice
13:35kennylevinsen: if only kdbus had worked out an become a proper, in-kernel IPC system...
13:41navi: 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
13:41navi: kdbus would've been so nice
13:42psykose: every time i see kdbus i think of kde dbus
13:44MrCooper: that was called DCOP ;)
13:47kennylevinsen: navi: I do find dbus-broker a bit nicer to work with
13:50navi: 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
13:50navi: any env in pam is a bad idea)
13:50navi: in the end it came out as a nice system that can be used fo other stuff too tho, like ssh-agent
14:10daniels: pq, mvlad, pH5: did any of you want to look at https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1277 or are you ok with it?
14:36pH5: daniels: I can't look past how there's inconsistent spacing between weston_buffer_reference and renderer->attach, otherwise it looks sane to me.
14:38daniels: pH5: hahaha thanks, will fix
15:00wlb: weston/main: Philipp Zabel * backend-vnc: render bypass support https://gitlab.freedesktop.org/wayland/weston/commit/72e2da24f9af libweston/backend-vnc/vnc.c
15:00wlb: weston Merge request !1266 merged \o/ (backend-vnc: render bypass support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1266)
15:55emersion: kennylevinsen: i find e.g. varlink a much better alternative
17:07wlb: weston Merge request !1278 opened by Derek Foreman (derekf) Rework 2D coordinate handling part 7 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1278 [XWayland], [Desktop shell], [libweston API]
19:49wlb: weston/main: Michael Tretter * backend-drm: print failing output in error message https://gitlab.freedesktop.org/wayland/weston/commit/98e398e78bc8 compositor/main.c
19:49wlb: weston/main: Michael Tretter * backend-drm: add config option require-outputs https://gitlab.freedesktop.org/wayland/weston/commit/20508c148e3a compositor/main.c man/weston.ini.man
19:49wlb: weston/main: Michael Tretter * backend-drm: change default for required-outputs to any https://gitlab.freedesktop.org/wayland/weston/commit/914be30bc0eb compositor/main.c man/weston.ini.man
19:49wlb: weston Merge request !1246 merged \o/ (backend-drm: fail initialization only if all outputs failed https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1246)
21:36DodoGTA: Has there been any discussion on raw input support/protocol for Wayland?
21:36qyliss: DodoGTA: do you know libei?
21:37DodoGTA: qyliss: I've never heard of that
21:37qyliss: https://gitlab.freedesktop.org/libinput/libei
21:40jadahl: DodoGTA: unless https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/110 is what you're after
21:41wlb: wayland-protocols Issue #146 opened by Simon Ser (emersion) EFL/Enlightenment participation https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/146
21:42emersion:trying not to repeat the weston fiasco…
21:48emersion: could we maybe add a GitLab subgroup for w-p members?
21:48emersion: that would allow someone to ping all w-p members in issues and such
21:48emersion: e.g. for governance stuff
21:51DodoGTA: jadahl: I mean a game could receive mouse inputs without any weird mouse acceleration for example
21:52wlb: wayland Issue #379 closed \o/ (Lowering inactive developers/maintainers to reporters https://gitlab.freedesktop.org/wayland/wayland/-/issues/379)
21:53emersion: there is the relative-pointer protocol for this
22:34DodoGTA: emersion: That wouldn't work for osu! because that game involves moving the cursor around the screen
22:36bl4ckb0ne: wasnt there an input fd protocol in the works?
22:36qyliss: that's what jadahl linked above if I'm not mistaken
22:37bl4ckb0ne: it is!
22:38bl4ckb0ne: they have the same color as wlb on goguma and i matched the two message as gitlab action and skipped them
22:42zamundaaa[m]: DodoGTA: you can still move the cursor around with the relative pointer protocol