ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Brainium has quit [Quit: Konversation terminated!]
Group-Deed has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
Guru_DE has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru__ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
tombl has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
CME_ has quit [Read error: Connection reset by peer]
CME has joined #wayland
tombl has joined #wayland
Guru_DE has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
tombl_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
tombl has quit [Ping timeout: 480 seconds]
tombl_ is now known as tombl
guru__ has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
guru_ has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
kts has joined #wayland
guru__ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
bjorkint0sh has quit [Remote host closed the connection]
fossdd has quit [Remote host closed the connection]
kts has joined #wayland
fossdd has joined #wayland
feaneron has joined #wayland
feaneron has quit [Quit: feaneron]
mart has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
<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!
garnacho has joined #wayland
<pq>
gives some kind of a closure to the matter, even if temporary
kts has quit [Ping timeout: 480 seconds]
<daniels>
++
peeterm has quit [Quit: Leaving]
peeterm has joined #wayland
kts has joined #wayland
<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.
<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
<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.
<bookworm>
if basically everyone but you thinks a certain way, maybe it's time to re evaluate the situation a bit?
<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.
<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
<pq>
yes, that ^
feaneron has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<kennylevinsen>
(of course the community should work towards broadening consensus if possible where an interested party has feedback or concerns)
<daniels>
exactly what pq & kenny said
<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?
<pq>
I'm not sure there was any standard when Weston gained its RDP-backend. After that, inertia, I'd say.
<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.
<jadahl>
swick[m]: please stop disrepresenting the actions (or lack of thereof) by GNOME reps, it's very disrespecting
<kennylevinsen>
but it would be nice if, even though they have built-in backends, that they supported external ones...
<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".
<pq>
Weston's old screen-share was actually "external" in its own horrible way.
<pq>
weston/RDP was a separate process from the Weston connected to by apps.
<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
<pq>
I'd welcome a generic pipewire/libei thing to Weston, too.
<any1>
pq: Yeah, I remember. I tried it, and decided to make my own thing because of how bad it was.
<jadahl>
pq: I'll ping you when I've finished my draft proposal. anyhow, have to go afk.
feaneron has quit [Quit: feaneron]
<any1>
jadahl: Well, that leads me to another question. Why not just use wayland protocols for that?
<pq>
jadahl, I'd welcome. Not necessarily I'd review. :-)
feaneron has joined #wayland
<pq>
any1, why should they be a Wayland protocol? There must be a reason for it.
<any1>
pq: I think that it would be simpler to have them be wayland protocols. It also requires fewer dependencies.
<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.
<daniels>
any1: s/fewer/different/
<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
<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. ;-)
<pq>
hence things like libei sound very attractive to me
<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.
<daniels>
I guess it just depends what you want to do with it from then on in, right
<daniels>
if you want to encode to H.264 then that's some complexity in and of itself
feaneron has quit [Quit: feaneron]
<kennylevinsen>
can pipewire do transforms on video, e.g. color conversions or encoding, or do you just get the source frames as is?
<daniels>
if you want to stream over a network with decent throughput but relatively high latency, that's also some complexity
<any1>
daniels: Sure, but pipewire can't encode h264 for me afaik. You can pipe it to gstreamer, but I prefer ffmpeg.
<daniels>
gstreamer can encode to h264, and pipewire also has a plugin to encode h264 via ffmpeg if you prefer
<daniels>
the point being that you accumulate external dependencies anyway, once you get beyond the point of 'great! I've got a frame'
<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
<jadahl>
any1: I don't see any benefit, only drawbacks, of replicating what libei and pipewire does in wayland
<jadahl>
any1: pipewire is just a pipe, it can pipe raw pixel data, or h264, or anything else
kts has joined #wayland
<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. ;)
<daniels>
and me!
<daniels>
another way of saying 'continue to be lazy' is 'not have to pretend to be competent at writing multimedia applications'
<any1>
daniels: Yes, they can leave that to other people, regardless of whether they choose libei & pipewire or wayland protocols.
<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
<any1>
kennylevinsen: Yes, I was about to point out the same thing. Thanks
<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.
<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.
feaneron has joined #wayland
<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.
glennk has joined #wayland
<daniels>
yeah, that's a load-bearing 'only' :P
feaneron has quit []
feaneron has joined #wayland
<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.
<any1>
Really, the first part, i.e. pixel pushing, what the compositor needs to implement, is easy.
<any1>
(with regards to multimedia requirements)
<any1>
Pushing it through w-p takes at least 2 years, though, for some reason...
<pq>
I thought pipewire is an IPC framework, and not something that apps use for internal things. Does it not have format negotiation?
<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
<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.
<pq>
what about service discovery, routing policies, authorization...
<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
* daniels
shrugs
<daniels>
weston's pipewire backend is 1121 LoC
<daniels>
I'm not convinced a screencopy implementation would be less code
kts has quit [Ping timeout: 480 seconds]
<any1>
It might be about the same, but it wouldn't depend on pipewire.
<daniels>
right, and personally I don't see that dependency as problematic in any way, but ymmv :)
privacy has joined #wayland
flokli has quit [Quit: WeeChat 4.2.2]
<any1>
Besides, there still needs to be some protocol implemented for discoverability of screen capturing sources. You need to get the stream from somewhere
kts has joined #wayland
<any1>
as far as I understand weston just has a pipewire backend, so you can't really use it for screencapturing?
<daniels>
a lot of our work over the past little while has been about having backends coexist and making overlapping outputs work
<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
<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.
mvlad has joined #wayland
<daniels>
enjoy!
fmuellner has joined #wayland
flokli has joined #wayland
<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
<vyivel>
or is rc1 too late
privacy has quit [Quit: Leaving]
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
feaneron has quit []
feaneron has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
fossdd has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
melonai has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<kennylevinsen>
either way I imagine syncobj only intended to sync content-full buffers, rather than what is a request to unmap
<kennylevinsen>
(The nil buffer is pending in that it is double buffered state, so "technically yes")
feaneron has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
riteo has quit [Ping timeout: 480 seconds]
feaneron has quit []
<zamundaaa[m]>
swick: yes it is. Had the same bug in KWin before :D
<zamundaaa[m]>
Unfortunately, fixing that still doesn't stop Firefox from crashing. It does bad things with threads that trigger other protocol errors
<swick[m]>
mh? if nil is considered a pending buffer then the firefox behavior seems broken.
<zamundaaa[m]>
Uh sorry, I meant to write it isn't. The intended behavior of the protocol error is quite clear at least
leon-anavi has quit [Quit: Leaving]
<swick[m]>
oh, I just can't read
<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.
<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
<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).
<JoshuaAshton>
At least on Deck OLED we can do 800+ nit sustained full frame, but our form factor is much more forgiving :P
nerdopolis has joined #wayland
privacy has quit [Remote host closed the connection]
gusnan has quit [Ping timeout: 480 seconds]
gusnan has joined #wayland
caveman has quit [Remote host closed the connection]