07:46 pq: emersion, I haven't read much any of the xdg-toplevel-icon discussions for a long time, but I do feel happy about you landing it because the governance requirements have been fulfilled. A good call!
07:47 pq: gives some kind of a closure to the matter, even if temporary
07:49 daniels: ++
08:06 swick[m]: The MR was an adversarial situation where people were not interested in finding consensus and reducing scope until consensus could be found. they got away with it because the only thing that would have forced them to find consensus was a NACK but while no one at GNOME wanted the protocol, the GNOME reps were too scared to NACK something because of the negative repercussions.
08:09 swick[m]: The system is broken and this has set a horrible precedence, showing that one can force their way because NACKs are considered to be a horrible thing
08:10 swick[m]: vetos exist because they require people to find consensus. if we don't use vetos when there isn't consensus there is no incentive to find consensus.
08:16 bookworm: if basically everyone but you thinks a certain way, maybe it's time to re evaluate the situation a bit?
08:16 pq: My perception is that there cannot be a concensus in some matters. All avenues of discussion have been exhausted. At that point one should acknowledge that there is no single standard for this thing, and move on. At least competing standards allow for more experience to be gained so that maybe there will be a third one better than both.
08:20 kennylevinsen: also note that there is a difference between being unanimous and having consensus - vetos are not for when one disagrees, but for when something is so bad that you need to overrule any consensus that would otherwise have been sufficient to pass
08:21 pq: yes, that ^
08:26 kennylevinsen: (of course the community should work towards broadening consensus if possible where an interested party has feedback or concerns)
08:27 daniels: exactly what pq & kenny said
08:35 any1: Why do Weston, Mutter and KWin implement their own built-in remote desktop solutions instead of implementing standards that would allow for external solutions?
08:37 pq: I'm not sure there was any standard when Weston gained its RDP-backend. After that, inertia, I'd say.
08:37 kennylevinsen: To be fair, even wlroots had an RDP backend - we just had issues with it and found the idea of external servers to be better and more flexible.
08:38 jadahl: swick[m]: please stop disrepresenting the actions (or lack of thereof) by GNOME reps, it's very disrespecting
08:38 kennylevinsen: but it would be nice if, even though they have built-in backends, that they supported external ones...
08:39 pq: I think it may have also been mixed with concerns about Wayland's fundamental design. It wasn't as well solidified as it is today. There was fear of turning a Wayland compositor into another externally controlled free-for-all "Xorg".
08:40 pq: Weston's old screen-share was actually "external" in its own horrible way.
08:40 pq: weston/RDP was a separate process from the Weston connected to by apps.
08:40 jadahl: any1: GNOME uses pipewire and libei for remote desktop / screen share like things. I'm interested in creating vendorless API using it (besides the portal ones). it wouldn't really involve Wayland though
08:41 pq: I'd welcome a generic pipewire/libei thing to Weston, too.
08:41 any1: pq: Yeah, I remember. I tried it, and decided to make my own thing because of how bad it was.
08:42 jadahl: pq: I'll ping you when I've finished my draft proposal. anyhow, have to go afk.
08:42 any1: jadahl: Well, that leads me to another question. Why not just use wayland protocols for that?
08:42 pq: jadahl, I'd welcome. Not necessarily I'd review. :-)
08:43 pq: any1, why should they be a Wayland protocol? There must be a reason for it.
08:44 any1: pq: I think that it would be simpler to have them be wayland protocols. It also requires fewer dependencies.
08:44 pq: FWIW, Weston still does not have a flexible solution on authorizing Wayland clients for privileged things, and I don't know what it could be.
08:45 daniels: any1: s/fewer/different/
08:46 daniels: you'd still depend on a complex Wayland protocol which would need many of the mechanics of a multimedia framework to be generically usable
08:46 pq: To me, dependecies are always a trade-off between pulling stuff in and having to put in the work oneself. The lazy me prefers other people doing my work. ;-)
08:47 pq: hence things like libei sound very attractive to me
08:48 any1: daniels: Well, I think that implementing wlr-screencopy-v1 and the virtual input protocols wasn't very complex. Pipewire seems like overkill to me.
08:49 daniels: I guess it just depends what you want to do with it from then on in, right
08:49 daniels: if you want to encode to H.264 then that's some complexity in and of itself
08:49 kennylevinsen: can pipewire do transforms on video, e.g. color conversions or encoding, or do you just get the source frames as is?
08:50 daniels: if you want to stream over a network with decent throughput but relatively high latency, that's also some complexity
08:50 any1: daniels: Sure, but pipewire can't encode h264 for me afaik. You can pipe it to gstreamer, but I prefer ffmpeg.
08:51 daniels: gstreamer can encode to h264, and pipewire also has a plugin to encode h264 via ffmpeg if you prefer
08:52 daniels: the point being that you accumulate external dependencies anyway, once you get beyond the point of 'great! I've got a frame'
08:52 daniels: so that's personally why I don't place a super-high value on the approach of making just the first step use inline Wayland protocol
08:52 jadahl: any1: I don't see any benefit, only drawbacks, of replicating what libei and pipewire does in wayland
08:53 jadahl: any1: pipewire is just a pipe, it can pipe raw pixel data, or h264, or anything else
08:54 any1: daniels: I'd say that from the compositor implementer's point of view, external dependencies are better than internal ones. They're beyond the scope of the compositor, so pq can continue to be lazy. ;)
08:55 daniels: and me!
08:55 daniels: another way of saying 'continue to be lazy' is 'not have to pretend to be competent at writing multimedia applications'
08:56 any1: daniels: Yes, they can leave that to other people, regardless of whether they choose libei & pipewire or wayland protocols.
08:57 kennylevinsen: from the compositor perspective, you do not have to be more competent at writing multimedia applications to pipe frames into a wayland protocol rather than piping them into pipewire
08:57 any1: kennylevinsen: Yes, I was about to point out the same thing. Thanks
09:00 any1: jadahl: The multimedia application is most likely going to want to do its own encoding in most cases, because only it knows exactly how things must be encoded. If they want to use pipewire or gstreamer internally, that's up to them.
09:02 any1: I.e. we only want the raw pixels from the encoder. E.g. for VNC, different clients need differente encoding formats. Some might want h264 and some might want RLE. Getting h264 via pipewire doesn't help in that case.
09:04 any1: The only tricky bits that require some knowledge about multimeda when it comes to screen capturing are presentation time and frame pacing. If the implementor of the protocol understands these things, then things will work out fine.
09:06 daniels: yeah, that's a load-bearing 'only' :P
09:09 any1: It's not that heavy. You attach the pts to the frame and design things such that frames don't get skipped and if you want to skip frames, you skip them at regular intervals.
09:09 any1: Really, the first part, i.e. pixel pushing, what the compositor needs to implement, is easy.
09:10 any1: (with regards to multimedia requirements)
09:11 any1: Pushing it through w-p takes at least 2 years, though, for some reason...
09:13 pq: I thought pipewire is an IPC framework, and not something that apps use for internal things. Does it not have format negotiation?
09:13 kennylevinsen: I can't say I don't understand the case for compositors that already have pipewire wired directly into the compositor process, with the wayland-only approach helping more minimal compositors stay minimal
09:16 pq: minimalism depends... with a Wayland protocol, someone needs to write all the clients too, or at least a component that translates between Wayland and e.g. pipewire. Then you hope there aren't too big impedance mismatch between the two protocols.
09:17 pq: what about service discovery, routing policies, authorization...
09:17 kennylevinsen: Well, due to wlroots-based compositors already having taken that approach, both direct clients and the pipewire translation already exist and would be shared
09:20 daniels:shrugs
09:20 daniels: weston's pipewire backend is 1121 LoC
09:20 daniels: I'm not convinced a screencopy implementation would be less code
09:22 any1: It might be about the same, but it wouldn't depend on pipewire.
09:25 daniels: right, and personally I don't see that dependency as problematic in any way, but ymmv :)
09:26 any1: Besides, there still needs to be some protocol implemented for discoverability of screen capturing sources. You need to get the stream from somewhere
09:27 any1: as far as I understand weston just has a pipewire backend, so you can't really use it for screencapturing?
09:29 daniels: a lot of our work over the past little while has been about having backends coexist and making overlapping outputs work
09:30 daniels: so you can have a PipeWire or RDP defined output (defined by static config, which might suck for interactive desktop use but definitely doesn't suck for more embedded devices) which mirrors a given DRM output
09:34 any1: Well, I got my answer to my original question: Historical reasons and inertia. We'll have to agree to disagree on the whole protocols vs. libei&pipewire thing. I have to go and do other stuff. Cheers.
09:35 daniels: enjoy!
09:40 vyivel: any chances of getting https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/391/ into wayland 1.23? as mahkoh has pointed out, the current wording doesn't fully apply to kwin and weston (albeit because of a buggy impl it seems) so would be better to have it explicitly unspecified
09:41 vyivel: or is rc1 too late
12:36 swick[m]: no functional change so I'm for merging still merging it
13:32 wlb: weston/main: Michael Olbrich * backend-wayland: don't wait for one frame when starting the repaint loop https://gitlab.freedesktop.org/wayland/weston/commit/5e43ef81ae8b libweston/backend-wayland/wayland.c
13:32 wlb: weston Merge request !1487 merged \o/ (backend-wayland: don't wait for one frame when starting the repaint loop https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1487)
14:51 joantolo[m]: Hi, I'm trying to see if I can help with the colormanagement protocol and so, any recommendation of an HDR monitor?
21:03 swick[m]: https://gitlab.gnome.org/GNOME/mutter/-/issues/3504#note_2124072
21:04 swick[m]: is a nil buffer a pending buffer?
21:22 kennylevinsen: either way I imagine syncobj only intended to sync content-full buffers, rather than what is a request to unmap
21:25 kennylevinsen: (The nil buffer is pending in that it is double buffered state, so "technically yes")
21:38 zamundaaa[m]: swick: yes it is. Had the same bug in KWin before :D
21:39 zamundaaa[m]: Unfortunately, fixing that still doesn't stop Firefox from crashing. It does bad things with threads that trigger other protocol errors
21:40 swick[m]: mh? if nil is considered a pending buffer then the firefox behavior seems broken.
21:40 zamundaaa[m]: Uh sorry, I meant to write it isn't. The intended behavior of the protocol error is quite clear at least
21:44 swick[m]: oh, I just can't read
21:44 swick[m]: > Clients must set both acquire and release points if and only if a non-null buffer is attached in the same surface commit.
21:46 swick[m]: joantolo: technically you only need a monitor that supports HDR signalling to work on HDR stuff but more capable monitors will be easier to debug on and experiment with
21:46 JoshuaAshton: joantolo[m]: I use an ASUS ROG Swift PG32UQX, it's quite nice, albeit LCD. Unfortunately every OLED monitor out there has attrocious full frame brightness values that make them nigh unusable IMO (Like < 200 nit).
21:47 JoshuaAshton: At least on Deck OLED we can do 800+ nit sustained full frame, but our form factor is much more forgiving :P