ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
eruditehermit has quit [Ping timeout: 480 seconds]
plutonium has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Hypfer has joined #wayland
feaneron has joined #wayland
<soreau>
emersion: I doubt compositors will start jumping for frog extensions
<soreau>
no pun intended :P
<soreau>
any1: hehe
<Eighth_Doctor>
soreau: I think it's probably not a good idea to presuppose that.
<llyyr>
soreau: kwin seems to have an implementation ready to go
<Eighth_Doctor>
yep
<Eighth_Doctor>
and of course gamescope exists too
yshui has quit [Remote host closed the connection]
yshui has joined #wayland
Company has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
Company has joined #wayland
Brainium has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Moprius has joined #wayland
Brainium has joined #wayland
Company has quit [Quit: Leaving]
kts has joined #wayland
mxz__ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
vincejv_ has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
yshui has quit [Remote host closed the connection]
vincejv_ has quit []
vincejv has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
yshui has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
yshui has quit [Remote host closed the connection]
yshui has joined #wayland
yshui has quit [Remote host closed the connection]
yshui has joined #wayland
eruditehermit has joined #wayland
yshui has quit [Remote host closed the connection]
yshui has joined #wayland
<colinmarc>
it seems obvious that valve has the power to fork wayland, even if they don't really want to
vincejv_ has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
<soreau>
probably wouldn't be any different than the severe fragmentation that exists already
<colinmarc>
one observation: a lot of w-p design discussions center around The Right Thing, and ignore survival characteristics of the thing. https://dreamsongs.com/RiseOfWorseIsBetter.html
crazybyte has quit [Read error: Connection reset by peer]
crazybyte has joined #wayland
bookworm has joined #wayland
<soreau>
(probably would be more like android, where they make their own thing and don't really care about foss all that much)
<colinmarc>
idk, they seem to be making a huge fuss about upstreaming so far
<soreau>
but it would be a nice side effect if steam worked native on wayland-ish thing somehow
<soreau>
colinmarc: I mean like surface/audio flinger and the api's that they need to support them
<colinmarc>
by they I meant valve
<soreau>
hm
rv1sr has joined #wayland
lockywolf has joined #wayland
sima has joined #wayland
eruditehermit has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
rasterman has joined #wayland
mclasen has joined #wayland
glennk has joined #wayland
eruditehermit has joined #wayland
coldfeet has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest4396
mclasen has quit [Ping timeout: 480 seconds]
kestrel has joined #wayland
MrCooper_ is now known as MrCooper
<kode54>
soreau: I mean, misyl is a valve employee
<kode54>
also here on this channel right now under dead name
vincejv_ has quit []
leon-anavi has joined #wayland
vincejv has joined #wayland
Company has joined #wayland
mclasen has joined #wayland
mclasen has quit [Quit: Leaving]
iomari891 has joined #wayland
narodnik has joined #wayland
eruditehermit has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
___nick___ has joined #wayland
feaneron has joined #wayland
kts has joined #wayland
cmichael has joined #wayland
kts has quit [Quit: Leaving]
nerdopolis has joined #wayland
shider has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Leaving]
Moprius has joined #wayland
selckin has joined #wayland
mclasen has joined #wayland
agd5f_ has quit []
agd5f has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mclasen has quit [Read error: No route to host]
mclasen has joined #wayland
mclasen_ has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
mclasen_ has quit [Ping timeout: 480 seconds]
mclasen_ has joined #wayland
mclasen__ has joined #wayland
mclasen_ has quit [Ping timeout: 480 seconds]
danie1dg has joined #wayland
kts has joined #wayland
danieldg has quit [Ping timeout: 480 seconds]
yshui_ has joined #wayland
Brainium has joined #wayland
yshui has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
yshui has joined #wayland
yshui_ has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
yshui_ has joined #wayland
yshui has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
feaneron has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
kts has joined #wayland
yshui_ has quit [Ping timeout: 480 seconds]
shider has joined #wayland
yshui has joined #wayland
yshui_ has joined #wayland
yshui has quit [Ping timeout: 480 seconds]
yshui has joined #wayland
yshui_ has quit [Ping timeout: 480 seconds]
abhimanyu has joined #wayland
kts has quit [Quit: Leaving]
plutonium has quit [Remote host closed the connection]
throwthecheese has joined #wayland
* throwthecheese
squeaks
yshui_ has joined #wayland
mclasen__ has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
bl4ckb0ne: I will gladly take short-term fragmentation as opposed to waiting half a decade for FIFO to not be broken in different ways.
yshui has quit [Ping timeout: 480 seconds]
<bl4ckb0ne>
what kind of guaranteed we have it's a short-term one?
<JoshuaAshton>
the only people who can guarantee that are compositor vendors
<bl4ckb0ne>
ive been thinking about proposing an "experimental" folder this morning, with something like 1-2 acks required to merge so we can iterate faster on the protocols before having a proper review and moving it in staging
<JoshuaAshton>
i mean fundamentally that is really no different to what i am proposing, and changes nothing in terms of how you should feel about fragmentation imo
<llyyr>
isn't taht what staging/ is supposed to be?
<bl4ckb0ne>
the experimental folder would be in w-p
<vyivel>
from the way staging/ is described in w-p's readme, it *is* the experimental folder
<vyivel>
at least that's how i read it
rasterman has quit [Quit: Gettin' stinky!]
<llyyr>
yeah, that's how I understood it as well. It's however an unwritten rule that anything that gets merged into w-p must be perfect from the get go
<llyyr>
so I'm not sure creating another folder solves anything unless you can actually change that mindset
<JoshuaAshton>
bl4ckb0ne: it sounds like you actually like the idea, but you are only against it because it's not your folder
coldfeet has joined #wayland
<karolherbst>
The discussion/topic is already heated as it is, so please refrain from any sort of personal attacks and stay constructive
<vyivel>
"an unwritten rule that anything that gets merged into w-p must be perfect from the get go" agree, this seems to be the core problem
nerdopolis has joined #wayland
leon-anavi has quit [Quit: Leaving]
<bl4ckb0ne>
i mean, who would not want to see protocols not stuck in review for a year
<llyyr>
It's not a people problem, it's a systematic issue. I don't think anyone wants to see a protocol that nobody really disagrees with being a good idea be stuck for 3 years with no reviews and no acks
<JoshuaAshton>
to be clear, i do not care whether it is my or your folder, i am more than happy for an "experimental" in w-p, and would be happy with that approach. but i think there are other issues than just that, primarily with the current governance model not being conducive to actually allowing that. this was already tried this with `staging`, and it didn't happen.
<vyivel>
hm how's the current governance model prohibiting that?
yshui_ has quit [Ping timeout: 480 seconds]
<kennylevinsen>
It’s not really what staging is right now - staging is where stuff ends after the full process, and when it has been there for long enough without changes we mark it stable. Experimental is something else entirely, although how that would work in practice is not so obvious.
throwthecheese has quit [Read error: Connection reset by peer]
<kennylevinsen>
Does something that has highly active discussions about fundamentals get to be in experimental? Do we entirely ignore that clients end up depending on “experimental” protocols and rip it out once the real one comes along?
<vyivel>
the problem is that people don't see it as a testing phase
<vyivel>
afraid of N>1 in _vN maybe, dunno
<vyivel>
not gonna guess
<JoshuaAshton>
vyivel: there is basically no representation for clients other than two toolkits, Qt and GTK, the latter of which is already serviced by the Mutter members which are the same. every wlroots compositor is represented by Simon and Simon. there is no representation for "mesa", and doing that would be basically impossible.
<kennylevinsen>
It can’t really be that way as clients implement stuff once it goes to staging - we stopped renaming protocols too because it was too disruptive
mclasen__ has joined #wayland
<vyivel>
JoshuaAshton: a good point, yes
<JoshuaAshton>
that's just the "technicals" anyway
yshui has joined #wayland
<JoshuaAshton>
i will refrain from talking about how the current setup affects the way people behave and treat differing opinions and usecases, although, I would say that's probably the larger deal, but basically impossible to action upon
mclasen__ is now known as mclasen
<JoshuaAshton>
really the governance model needs to go away, and it just becomes controlled anarchy like Mesa is, at least in my opinion.
<zamundaaa[m]>
kennylevinsen: experimental protocols couldn't be ripped out of wayland-protocols, but compositor developers can very much deprecate and remove them, forcing a transition to stable protocols at some point. Or, if it's not a lot of maintenance overhead, just keep them
<zamundaaa[m]>
The frog color management protocol for example is quite simple, and there's no reason to drop it in KWin anytime soon, as it maps to the same core functionality as the upstream protocol
<JoshuaAshton>
i outlined some decent groundrules for making iteration on things like that in f-p less painful and with less churn -- the tl;dr is that you also do method_v2 if it's possible when in the experimental/frog phase.
alatiera3 has joined #wayland
<emersion>
i don't think the governance model is actually the problem, fwiw
cmichael has quit [Quit: Leaving]
alatiera3 is now known as alatiera
<kennylevinsen>
I don’t completely oppose the idea of a formal way to deal with protocols in a proposal stage rather than ones that are ready, but I’m not a big fan of an entirely different repo that possibly takes stuff out of context and could end up just being a means to bypass/ignore commentary
<emersion>
protocols are stalled not because of the governance, but because of lack of manpower and unresolved discussions
<JoshuaAshton>
the majority of these unresolved discussions are just bad-faith arguments (eg. window icons) or people thinking of theoreticals that can be addressed post-humously and would likely be found and discussed much better if people went to implement and use it in some form.
<mclasen>
making working protocols is hard
<mclasen>
and it is true that the wayland protocols process lacks early experimentation and iteration
<Company>
the worst thing about the Wayland protocols process is that projects often fundamentally don't agree on the protocols
<JoshuaAshton>
implementation is optional.
<Company>
yeah, but that's not how projects act
Moprius has joined #wayland
<Company>
it'd be fine if - just like with Vulkan/GL with GL_EXT_NV_whatever - there was those frog_ or kde_ or gtk_ or whatever protocols
<Company>
with a similar process of getting the useful ones turned into more accepted ones
<vyivel>
that would be nice too
<vyivel>
some wlr-/cosmic- protocols could be merged this way
<bl4ckb0ne>
gl exts still have the same review process, regardless of the vendor
<Company>
I think what JoshuaAshton runs into is that gamescope/mesa is a weird combo because it's somewhat different projects
<Company>
whereas kde and gtk have an estalished communication path that they can use for their protocols
<emersion>
steamos van run with mesa patches if they'd like to experiment
<zamundaaa[m]>
fifo isn't really about gamescope, it's primarily about Wayland clients running on desktop compositors
<emersion>
can
nerdopolis has quit [Ping timeout: 480 seconds]
<mclasen>
looking at the speed at which we're replacing the gtk-shell protocol, I'm not sure we're in a much better position
<zamundaaa[m]>
Company: the difference to other vendor specific protocols is that we in KDE can't just implement the protocol and get anything out of it
<Company>
bl4ckb0ne: I don't actually know how it works in detail, but I know that the Vulkan spec is full of constants that exist 3 times: once as a vendor thing, once as a KHR/EXT thing and then finally without anything once it got merged into core
<Company>
zamundaaa[m]: yeah, that only works for some kinds of protocols - if kwin needs something out of the Mesa wsi or out of GTK, it gets more complicated
<JoshuaAshton>
emersion: we already have for over a year, but implemented in a layer.
<Company>
but ultimately, I don't see a problem - if a compositor and a client agree to do some protocol, they should go for it. As long as there's an understanding that they might want to throw it away later when a "proper" protocol gets made from it or the whole idea gets scrapped
drakulix[m] has joined #wayland
<drakulix[m]>
[@_oftc_vyivel:matrix.org](https://matrix.to/#/@_oftc_vyivel:matrix.org)I honestly don’t care where cosmic-protocols reside. If any other comp wants to implement them, we can just push it through to the ext-namespace.
<drakulix[m]>
I have been meaning to review and most likely ack ext-data-control in the next couple of ways the same way.
plutonium has joined #wayland
<drakulix[m]>
*days
<JoshuaAshton>
why should SteamOS be the only place you can actually use Wayland WSI and not suffer massively deterimental GPU-bound performance because of politics :s
<JoshuaAshton>
the only person that screws over is end users :/
plutonium has quit [Remote host closed the connection]
<DemiMarie>
What about ensuring that the experimental branch is actually unstable?
<DemiMarie>
Renaming protocols at every release for example
plutoneon has joined #wayland
<vyivel>
drakulix[m]: there's at least one compositor i'm aware of (labwc) that wants to have workspaces
<Company>
DemiMarie: that doesn't really work because compositors and apps don't release in lockstep
<drakulix[m]>
@Demi That is what the xx-namespace (see e.g. color-management) is providing already.
<Company>
DemiMarie: and if you try to make it work in a flatpak world, it gets even harder
yshui_ has joined #wayland
<zamundaaa[m]>
Demi: the only way to ensure it is if compositors and/or clients drop support for it at some point
<DemiMarie>
Company: Flatpaks and stable distros would build with experimental features disabled, except for alpha or beta flatpaks.
<Company>
DemiMarie: Steam is a flatpak...
<DemiMarie>
This is meant for bleeding edge rolling release distros and for experimental builds.
<DemiMarie>
If a client doesn't have a fallback for an experimental protocol being missing, it is buggy.
<zamundaaa[m]>
Demi: fallbacks are one thing, having functionality work is another
<mclasen>
but thats not what experimental protocols are for - they're for experiments
<DemiMarie>
zamundaaa: experimental protocols are for experimental functionality that is off by default
<DemiMarie>
Firefox would only use them in Nigbtky
<DemiMarie>
Nightly
<zamundaaa[m]>
Demi: no, off by default is not what we're going for here at all
yshui has quit [Ping timeout: 480 seconds]
<DemiMarie>
zamundaaa: ah, okay
<Company>
this is more a case of new features
<Company>
not experimental stuff
<DemiMarie>
My reasoning is that experiments should not find their way into stable releases.
<mclasen>
the xx protocols are off by default in mutter
<mclasen>
and that is as it should be, imo
<DemiMarie>
Oh
<DemiMarie>
mclasen: exactly
<zamundaaa[m]>
Demi: "experimental" doesn't mean "will blow up in your face" but "the protocol design isn't complete yet"
<DemiMarie>
zamundaaa: I think such protocols are best suited for distro packages that can rebuild everything if necessary.
<DemiMarie>
Especially distros like Arch where there is already no expectation of stability and a lot of coordination between packagers.
<zamundaaa[m]>
Rebuilds don't change anything for experimental protocols
<DemiMarie>
The only way I can think of to avoid ossification is to be willing to make regular breaking changes.
<zamundaaa[m]>
Nothing of the sort is necessary
<DemiMarie>
What am I missing?
<DemiMarie>
I don't think something like Debian Stable or Alma Linux wants protocols that aren't finished.
<zamundaaa[m]>
All it takes to move to a new protocol is for a major compositor to drop the old one
<zamundaaa[m]>
Demi: again, don't confuse "experimental" with "not good"
<drakulix[m]>
[@_oftc_vyivel:matrix.org](https://matrix.to/#/@_oftc_vyivel:matrix.org)Then they should review and acknowledge ext-workspaces. That is literally my PR, cosmic-workspaces is modeled after it, and I would be happy to merge it.
<DemiMarie>
zamundaaa: I suspect LTS distros don't want experimental protocols no matter how good they are.
<DemiMarie>
Not everything is a rolling release.
<Company>
DemiMarie: distros just ship upstream
yshui has joined #wayland
<Company>
DemiMarie: usually with --enable-all-optional-features
<zamundaaa[m]>
Demi: rolling release has nothing to do with this
<DemiMarie>
zamundaaa: so I am even more confused now
<DemiMarie>
If an app relies on experimental features and those get dropped, then the app will be broken unless updated.
<Company>
usually those are extra features
<zamundaaa[m]>
LTS doesn't ship feature updates of compositors or apps
<Company>
that the app has fallback for / can disable
<zamundaaa[m]>
as a general rule
yshui_ has quit [Ping timeout: 480 seconds]
<llyyr>
That, and why would the distro update the wayland-protocols but not the app which should have accompanying changes after the experimental protocol got dropped?
<mclasen>
you can't really ship 'the protocols'
<mclasen>
you ship compositors and client-side tooling implementing them
<DemiMarie>
llyyr: I'm thinking of cases where the compositor and client are out of sync
<llyyr>
That's a distro issue, and can happen currently as well even without the experimental folder
<DemiMarie>
Old compositor with new flatpak client for example
<DemiMarie>
Or old client on newer distro
<Company>
that doesn't really happen
<zamundaaa[m]>
That problem is independent of experimental protocols
<llyyr>
^
<Company>
because clients run without optional protocols anyway
<DemiMarie>
Ack
<Company>
and we don't do the mandatory stuff as experimental anymore
<DemiMarie>
JoshuaAshton: what is wrong with the Wayland WSI?
<bl4ckb0ne>
everything? /s
<llyyr>
It is explained in the Mesa MR and the linked libSDL PR
<DemiMarie>
Also, what is the bare minimum of a rendering API needed to properly implement a (rootless) Wayland compositor? Is being able to submit, damage, and commit buffers sufficient?
<Company>
and there's the whole scale/positioning question, not sure how relevant that is
<vyivel>
oh nice
<DemiMarie>
Company: I have a proxy that can do arbitrary format conversions. I'm more concerned about using the host compositor in as simple and as predictable a way as possible.
<DemiMarie>
I want to make sure that I take well tested compositor code paths and skip the ones that have hidden bugs.
<kennylevinsen>
depends on what you define as rootless - does it do the window management, or does it offload that to a nested compositor?
<DemiMarie>
Offloads it
<kennylevinsen>
If everything is offloaded, a tiny custom shell that allows arbitrary positioning and focus-less input
<kennylevinsen>
Not even that, fullscreen-shell would do the trick
<kennylevinsen>
Each nested toplevel just being a subsurface
<DemiMarie>
Ah, I misunderstood your question.
<DemiMarie>
This is itself a nested compositor.
<mclasen>
any examples of what you would want your proxy to shield the host compositor from ?
<DemiMarie>
Unexpected client behavior that could cause potentially-exploitable crashes is the main one.
yshui has quit [Ping timeout: 480 seconds]
<DemiMarie>
Also attempts to cover up things like headerbars.
<kennylevinsen>
protecting from just *unexpected* client behavior in a proxy is only really possibly by entirely decoupling it, allowing no traffic towards the host to be affected by a client, and… having a pretty useless compositor
<kennylevinsen>
Better to focus on hardening the host compositor against unexpected client behavior by e.g. fuzzing or proofs
yshui has joined #wayland
<kennylevinsen>
if you want a restricted host compositor with most window management in the nested compositor for isolation, then what is required depends on what you want the host compositor to be responsible for. The minimum is support for attaching one buffer per output, but if you want the host to handle things like input focus, then you also get into copy/paste, dnd, tablet devices, etc.
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
AJ_Z0 has quit [Read error: Connection reset by peer]
AJ_Z0 has joined #wayland
<DemiMarie>
That's really unfortunate. Qubes OS supports multiple X11 window managers and I would rather not lose that when switching to Wayland.
cool110 has joined #wayland
cool110 is now known as Guest4446
AJ_Z0 has quit [Remote host closed the connection]
AJ_Z0 has joined #wayland
Guest4396 has quit [Ping timeout: 480 seconds]
eruditehermit has joined #wayland
rv1sr has quit []
coldfeet has quit [Remote host closed the connection]
balrog_ has joined #wayland
balrog has quit [Ping timeout: 480 seconds]
Moprius has quit [Ping timeout: 480 seconds]
shider has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
yshui has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
yshui has joined #wayland
coldfeet has joined #wayland
AJ_Z0 has quit [Quit: I have to return some videotapes]
AJ_Z0 has joined #wayland
yshui has quit [Ping timeout: 480 seconds]
<colinmarc>
a lot of the stalled protocols are meant to be used by WSI, not by clients directly. what if the WSI was split out into a library that everyone could collaborate on? libwayland-wsi or whatever? That would address fragmentation because there would be fewer clients (for some protocols), and it would lower the bar to entry for protocols because there would only be one major client targeted (sorta like mesa is now)
plutoneon has quit [Remote host closed the connection]
<colinmarc>
<JoshuaAshton> "i outlined some decent groundrul..." <- does wayland need a way to not crash if a request/event isn't available? right now if I don't check the client version of a protocol in my compositor and send an event that the client doesn't know about, it usually blows up
yshui has joined #wayland
<ManMower>
that's a compositor bug, isn't it?
<vyivel>
it is
<colinmarc>
yes, right now it is. compare that to something like protobuf, which is much more resilient and backwards compatible in the face of changes. if you add fields, they are ignored by clients that don't know about those fields
<ManMower>
the idea of a malicious compositor intentionally blowing up well written clients isn't really something we put any thought into.
<ManMower>
and compositors that are properly written just shouldn't do that.
<DemiMarie>
I would write helper functions that do the version check internally and use those to send events.
<colinmarc>
this discussion is about wanting to make w-p more friendly to iteration and experimentation. one problem with that is that any change requires bumping the version of the entire protocol
<colinmarc>
* of the ~~entire protocol, * entire protocol~~ the entire interface
<DemiMarie>
You can always add new requests and events and declare old ones to be no-ops.
nysach has joined #wayland
<DemiMarie>
That requires a version bump but it is easy to implement on both sides.
nysach has quit [Remote host closed the connection]
<ManMower>
xdg-shell is probably a decent example of a protocol that had a long history of experimental implementations before becoming fully usable
<colinmarc>
DemiMarie: what if you're just adding an optional argument?
<DemiMarie>
colinmarc: No such thing in Wayland.
<DemiMarie>
Except for arrays and objects
<colinmarc>
yes it is? there are sometimes arguments which are allowed to be null
<DemiMarie>
Sorry, strings and objects
<DemiMarie>
Those still must be sent on the socket even if null, though.
<colinmarc>
explicit optional types are also great, btw, and not hard to write a wire representation for
<DemiMarie>
This sounds like a question for Wayland 2.0.
<ManMower>
are you saying you want to change a request/event signature between versions?
<DemiMarie>
I think that Colin Marc wants something where unexpected fields are ignored and missing fields have a default value.
mclasen has quit [Ping timeout: 480 seconds]
<colinmarc>
yeah, I'm suggesting protobuf-like semantics to make it painless to make small changes
<colinmarc>
protobuf is really cool - it's also provable whether a change is backwards or compatible or not, so you can write unit tests for it
<HW42>
kennylevinsen: DemiMarie, just pointed me to the discussion you had earlier here regarding a compositor that runs inside a VM that then talks a simple protocol to something on the host. she interpreted your message as that being practical. what's the problem here. sure you need to do some window mangement synchronization. but AFIUC wayland is more restrictive than X11 in what it allows a client to do. for
<HW42>
X11 our current solution works good enough for the majority of cases
eruditehermit has quit [Ping timeout: 480 seconds]
<HW42>
would that mean you have trouble to port a remote desktop client with seamless mode support to wayland?
___nick___ has quit [Remote host closed the connection]
<HW42>
PING 1727208350 50853
sima has quit [Ping timeout: 480 seconds]
throwthecheese has joined #wayland
<HW42>
(sorry about that PING, wrong tab completion)
<throwthecheese>
There really should be a way to set calibration matrices bypassing libXinput using libinput
<throwthecheese>
XOrg has this crappy behavior of not adding my stylus until I touch it to my screen
iomari891 has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
<Eighth_Doctor>
<drakulix[m]> "[@_oftc_vyivel:matrix.org](https..." <- labwc isn't a member, they're represented by wlroots, who hasn't done anything... KDE is also interested, I dunno if zzag or d_ed have looked at it yet to review it
pakcjo has joined #wayland
<pakcjo>
Hi, i'm trying to start weston and I'm getting weston_drm_format_add_modifier: Assertion `!weston_drm_format_has_modifier(format, modifier)' failed. no idea how to debug further :(
<Consolatis>
and yes, Eighth_Doctor is correct and labwc is not a member of w-p and I (one of the devs of labwc) did in fact review ext-workspaces multiple times
<DemiMarie>
zmike: honestly IRC's restrictions make it very hard to have multiple concurrent conversations in the same channel, which is very often needed in my experience.
nysach has joined #wayland
<Sachiel>
worked fine for me for decades
<Consolatis>
DemiMarie: the bridge could still use the IRC nickname rather than the full matrix address
<Eighth_Doctor>
Consolatis: you do a good job giving feedback despite not having any power :)
<Eighth_Doctor>
Consolatis: it does if you configure the bridge... I am certainly not Eighth_Doctor on the other side
<DemiMarie>
Consolatis: that's indeed a legitimate issue and should be reported as a bug if it has not been already.
nysach has quit [Remote host closed the connection]
eruditehermit has joined #wayland
<Eighth_Doctor>
<emersion> "steamos van run with mesa..." <- I would rather not they did that, since I want these enhancements for Fedora
<Eighth_Doctor>
so please let's not suggest things like this
Calandracas__ has joined #wayland
<mclasen>
nothing wrong with that suggestion
rv1sr has quit []
<Eighth_Doctor>
sure there is... it means nobody else gets these improvements
<Eighth_Doctor>
we'd never hear about them, or discover them
<Eighth_Doctor>
<DemiMarie> "My reasoning is that experiments..." <- I think the thing you're missing is that there is no such thing as experimental functionality in Wayland.
<Eighth_Doctor>
It basically never happens. Wayland protocols are developed to expose functionality that already exists or is expected to exist. Experimental implementations may exist, but the protocols themselves? Nope.
<mclasen>
everybody gets to play by the same rules - if you want everybody to benefit, upstream your things properly
<mclasen>
of course, its up to mesa developers to make that decision, but that would be my advice
<Eighth_Doctor>
does that mean you wouldn't implement an NVIDIA GL or Vulkan extension in mutter or gtk even if it's expected by everyone?
* ManMower
mumbles something about EGLStreams
<Eighth_Doctor>
I kind of see it in a similar light... and seemingly most wayland compositor developers do too
<mclasen>
so far I've seen zamundaa's opinion on this
<Eighth_Doctor>
I don't know of a single compositor that doesn't implement either private protocols, third party protocols, or both
<mclasen>
not sure that counts as most
<mclasen>
but anyway, up to mesa
<Eighth_Doctor>
sure
<kennylevinsen>
HW42: if by "remote dekstop client with seamless mode" you mean window forwarding, then waypipe already demonstrates that. Not sure how well wlfreedrp's RAIL mode works though, which is the windows equivalent.
<Eighth_Doctor>
IIRC, it's used by MS' weston fork, but that effort was not upstreamed into weston proper
* Eighth_Doctor
should see if he can poke and prod someone about that
<HW42>
kennylevinsen: yeah, so that sounds like this should be doable. obviously on the same host you would replace transmission of pixel data with references to shared memory
<kennylevinsen>
HW42: either way, many things are possible, what matters is the requirements and in particular what responsibility you want each part to have. If, for example, the "host compositor" needs to manage windows, input, focus, etc., then it quickly ends up needing to deal with copy-paste, dnd, and all sorts of other things to the point of the isolation being questionable
<kennylevinsen>
the other extreme is a host compositor that just accepts fully composited output buffers, which ends up sort of just being a KMS proxy
<kennylevinsen>
where your design intent is on that spectrum affects what you need, and whether it makes sense or is just a layer of complexity
<kennylevinsen>
HW42: the thing is, waypipe requires a full, normal compositor with all the bells and whistles, not just a thing that puts buffers where told
<kennylevinsen>
and DemiMarie's primary stated purpose of this was isolation from "unexpected client behavior", which would not be granted by such a solution
<kennylevinsen>
(such a solution: waypipe)
<HW42>
"waypipe requires a full, normal compositor", you mean at the remote side
<HW42>
(the less trusted side where the real clients run)
<kennylevinsen>
full, normal compositor where you want to see and interact with the app. Where the app is running there is no compositor dependency (other than the waypipe server itself, which proxies messages after some processing)
<kennylevinsen>
so it would run on the *trusted* side, at least within my perspective of trust
<HW42>
ok, then this doesn't sound like what we want
<kennylevinsen>
the compositor is also, in effect, the ultimate source of trust in the Wayland stack, effectively representing the user
<kennylevinsen>
that will also be true in your stack - the question is just what responsibility you give to the trusted host compositor, and what isolate to other (presumably lower trust) components
<HW42>
I mean obviously on the trusted side there needs to be a full normal compositor for the user, but that should only interact with the trusted part of the gui forwarding
<HW42>
currently with X11 on the host side and X11 or Windows on the client side that works reasonable well with a rathe minimalistic protocol. sure it has ugly corners, but overall works reasonable well
<HW42>
*rather
<kennylevinsen>
in that case, the forwarding will effectively be forwarding a desktop shell, input management, copy/paste, dnd, etc. as that is the responsibility of the host compositor - you can of course do that with a custom layer, but I can't help but wonder what is gained over just using the regular wayland protocols
<kennylevinsen>
you won't be isolated from "unexpected client behavior" anyhow - even if the client behavior is partially translated, it still ultimately pokes at the host
<kennylevinsen>
but to be clear, it's most certainly possible to have a custom protocol to the host, just don't see a whole lot of benefit
<kennylevinsen>
(DemiMarie also mentioned support for "multiple X11 window managers" right now, and being custom this would not support any off-the-shelf Wayland compositors)
<HW42>
for example you can filter windows sizes, title contents. copy/paste is only local (except some special copy from this domain to another triggerd by a gloabl short cut)
<HW42>
why would that not support of the shelf wayland compositors? they would just see a client that create window content from some shared memory that happens to come from somewhere else and that forwards events when focused
<kennylevinsen>
my comment was about custom protocols, which off-the-shelf compositors will neither speak when nested nor understand from clients
<kennylevinsen>
if all you're doing is running an off-the-shelf compositor on the host, and running a filtering proxy that exposes wayland protocols as-is apart from a few things you don't like, all is good
<kennylevinsen>
but that's quite different from guarding against blanket "unexpected client behavior"
<HW42>
okay, maybe I was unclear. the custom protocol (wheter this is something looking completly different or some very restrictive subset of wayland doesn't matter) would be talked between the component inside the vm that looks like a wayland compositor to it's in-VM clients and on the other hand the component that runs on the host and that act towards the "real" compostitor on the host as wayland client
<kennylevinsen>
Then you’re going from Wayland, to custom, to Wayland - what’s in the middle being mostly transparent to either side
<HW42>
yeah, and what I think DemiMarie wanted to ask was what function that custom part should expose so make integrating this into wayland on the both ends easy
<HW42>
*what functionality
<ericonr>
HW42:
<ericonr>
Sorry, ignore
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
iomari891 has joined #wayland
<kennylevinsen>
Well, when a client calls xdg_surface.get_toplevel, the host compositor needs to receive xdg_surface.get_toplevel, etc. - so anything in the middle needs to be transparent apart from the features you block/intercept. With that in mind, I’d pass things as is, but with an allowlist for protocols and interception of arguments you’d like to filter.
mclasen has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Otherwise you’re reinventing Wayland but with a different wire format
<kennylevinsen>
You can do that, but that just lands you in wine-esque window management primitive translation land, going from Wayland to your paradigm to Wayland
<kennylevinsen>
You could have the nested compositor pre-composite a single toplevel as if it ran in its own nested server, in which case there would be simpler communication to the server (a single toplevel - no popups or subsurfaces), but then the question isn’t what you need from Wayland, but what you implemented the nested compositor to use. But again, up to the requirements
glennk has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
colinmarc: that's why the compositor must check for the client version and why the version of objects exists
<Ermine>
I guess frog-protocols will become a dependency of mesa if that MR will be merged?
<HW42>
kennylevinsen: thanks, I think that mostly answers what DemiMarie was looking for
<Eighth_Doctor>
Ermine: yeah, though it shouldn't be a problem since it's available in Arch, Fedora, and openSUSE already
<soreau>
it's kinda like saying 'who needs khronos, we got this.'
<soreau>
when it might be the only thing controlling the anarchy
<Ermine>
Eighth_Doctor: I'm thinking of other distros, namely Alpine and Adélie
<Eighth_Doctor>
I think they won't have issues shipping it...
<Eighth_Doctor>
it's a build-time dependency only anyway
<llyyr>
Ermine: packaging it is trivial
<Ermine>
yes, but...
<JoshuaAshton>
Ermine: It has a wrap file, so it is not necessary to be packaged (just like wayland-protocols) -- but many distros have policies that require it.
<Ermine>
We have those too
roussinm has joined #wayland
roussinm has quit []
feaneron has quit [Ping timeout: 480 seconds]
yshui has quit [Ping timeout: 480 seconds]
yshui has joined #wayland
rebelsout has joined #wayland
rebelsout has quit [Remote host closed the connection]