01:31 soreau: emersion: I doubt compositors will start jumping for frog extensions
01:31 soreau: no pun intended :P
01:32 soreau: any1: hehe
01:38 Eighth_Doctor: soreau: I think it's probably not a good idea to presuppose that.
01:40 llyyr: soreau: kwin seems to have an implementation ready to go
01:40 Eighth_Doctor: yep
01:40 Eighth_Doctor: and of course gamescope exists too
05:18 colinmarc: it seems obvious that valve has the power to fork wayland, even if they don't really want to
05:31 soreau: probably wouldn't be any different than the severe fragmentation that exists already
05:32 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
05:36 soreau: (probably would be more like android, where they make their own thing and don't really care about foss all that much)
05:38 colinmarc: idk, they seem to be making a huge fuss about upstreaming so far
05:38 soreau: but it would be a nice side effect if steam worked native on wayland-ish thing somehow
05:39 soreau: colinmarc: I mean like surface/audio flinger and the api's that they need to support them
05:39 colinmarc: by they I meant valve
05:40 soreau: hm
08:45 kode54: soreau: I mean, misyl is a valve employee
08:45 kode54: also here on this channel right now under dead name
16:27 throwthecheese:squeaks
16:28 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.
16:29 bl4ckb0ne: what kind of guaranteed we have it's a short-term one?
16:30 JoshuaAshton: the only people who can guarantee that are compositor vendors
16:30 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
16:32 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
16:34 llyyr: isn't taht what staging/ is supposed to be?
16:38 bl4ckb0ne: the experimental folder would be in w-p
16:39 vyivel: from the way staging/ is described in w-p's readme, it *is* the experimental folder
16:39 vyivel: at least that's how i read it
16:40 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
16:40 llyyr: so I'm not sure creating another folder solves anything unless you can actually change that mindset
16:40 JoshuaAshton: bl4ckb0ne: it sounds like you actually like the idea, but you are only against it because it's not your folder
16:41 karolherbst: The discussion/topic is already heated as it is, so please refrain from any sort of personal attacks and stay constructive
16:42 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
16:45 bl4ckb0ne: i mean, who would not want to see protocols not stuck in review for a year
16:46 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
16:46 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.
16:47 vyivel: hm how's the current governance model prohibiting that?
16:50 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.
16:52 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?
16:52 vyivel: just looking at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main#protocol-phases
16:52 vyivel: "testing phase" matches staging/
16:53 vyivel: the problem is that people don't see it as a testing phase
16:53 vyivel: afraid of N>1 in _vN maybe, dunno
16:53 vyivel: not gonna guess
16:54 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.
16:54 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
16:54 vyivel: JoshuaAshton: a good point, yes
16:54 JoshuaAshton: that's just the "technicals" anyway
16:56 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
16:56 JoshuaAshton: really the governance model needs to go away, and it just becomes controlled anarchy like Mesa is, at least in my opinion.
16:56 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
16:57 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
16:58 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.
17:01 emersion: i don't think the governance model is actually the problem, fwiw
17:03 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
17:03 emersion: protocols are stalled not because of the governance, but because of lack of manpower and unresolved discussions
17:07 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.
17:09 mclasen: making working protocols is hard
17:09 mclasen: and it is true that the wayland protocols process lacks early experimentation and iteration
17:15 Company: the worst thing about the Wayland protocols process is that projects often fundamentally don't agree on the protocols
17:15 JoshuaAshton: implementation is optional.
17:15 Company: yeah, but that's not how projects act
17:17 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
17:17 Company: with a similar process of getting the useful ones turned into more accepted ones
17:18 vyivel: that would be nice too
17:18 vyivel: some wlr-/cosmic- protocols could be merged this way
17:19 bl4ckb0ne: gl exts still have the same review process, regardless of the vendor
17:19 Company: I think what JoshuaAshton runs into is that gamescope/mesa is a weird combo because it's somewhat different projects
17:19 Company: whereas kde and gtk have an estalished communication path that they can use for their protocols
17:20 emersion: steamos van run with mesa patches if they'd like to experiment
17:20 zamundaaa[m]: fifo isn't really about gamescope, it's primarily about Wayland clients running on desktop compositors
17:20 emersion: can
17:21 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
17:21 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
17:21 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
17:23 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
17:24 JoshuaAshton: emersion: we already have for over a year, but implemented in a layer.
17:25 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
17:25 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.
17:25 drakulix[m]: I have been meaning to review and most likely ack ext-data-control in the next couple of ways the same way.
17:25 drakulix[m]: *days
17:25 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
17:26 JoshuaAshton: the only person that screws over is end users :/
17:26 DemiMarie: What about ensuring that the experimental branch is actually unstable?
17:26 DemiMarie: Renaming protocols at every release for example
17:27 vyivel: drakulix[m]: there's at least one compositor i'm aware of (labwc) that wants to have workspaces
17:27 Company: DemiMarie: that doesn't really work because compositors and apps don't release in lockstep
17:28 drakulix[m]: @Demi That is what the xx-namespace (see e.g. color-management) is providing already.
17:28 Company: DemiMarie: and if you try to make it work in a flatpak world, it gets even harder
17:29 zamundaaa[m]: Demi: the only way to ensure it is if compositors and/or clients drop support for it at some point
17:29 DemiMarie: Company: Flatpaks and stable distros would build with experimental features disabled, except for alpha or beta flatpaks.
17:30 Company: DemiMarie: Steam is a flatpak...
17:30 DemiMarie: This is meant for bleeding edge rolling release distros and for experimental builds.
17:31 DemiMarie: If a client doesn't have a fallback for an experimental protocol being missing, it is buggy.
17:31 zamundaaa[m]: Demi: fallbacks are one thing, having functionality work is another
17:31 mclasen: but thats not what experimental protocols are for - they're for experiments
17:31 DemiMarie: zamundaaa: experimental protocols are for experimental functionality that is off by default
17:32 DemiMarie: Firefox would only use them in Nigbtky
17:32 DemiMarie: Nightly
17:32 zamundaaa[m]: Demi: no, off by default is not what we're going for here at all
17:32 DemiMarie: zamundaaa: ah, okay
17:32 Company: this is more a case of new features
17:32 Company: not experimental stuff
17:32 DemiMarie: My reasoning is that experiments should not find their way into stable releases.
17:32 mclasen: the xx protocols are off by default in mutter
17:33 mclasen: and that is as it should be, imo
17:33 DemiMarie: Oh
17:33 DemiMarie: mclasen: exactly
17:33 zamundaaa[m]: Demi: "experimental" doesn't mean "will blow up in your face" but "the protocol design isn't complete yet"
17:34 DemiMarie: zamundaaa: I think such protocols are best suited for distro packages that can rebuild everything if necessary.
17:34 DemiMarie: Especially distros like Arch where there is already no expectation of stability and a lot of coordination between packagers.
17:35 zamundaaa[m]: Rebuilds don't change anything for experimental protocols
17:36 DemiMarie: The only way I can think of to avoid ossification is to be willing to make regular breaking changes.
17:36 zamundaaa[m]: Nothing of the sort is necessary
17:37 DemiMarie: What am I missing?
17:38 DemiMarie: I don't think something like Debian Stable or Alma Linux wants protocols that aren't finished.
17:38 zamundaaa[m]: All it takes to move to a new protocol is for a major compositor to drop the old one
17:38 zamundaaa[m]: Demi: again, don't confuse "experimental" with "not good"
17:38 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.
17:39 DemiMarie: zamundaaa: I suspect LTS distros don't want experimental protocols no matter how good they are.
17:39 DemiMarie: Not everything is a rolling release.
17:39 Company: DemiMarie: distros just ship upstream
17:39 Company: DemiMarie: usually with --enable-all-optional-features
17:39 zamundaaa[m]: Demi: rolling release has nothing to do with this
17:40 DemiMarie: zamundaaa: so I am even more confused now
17:40 DemiMarie: If an app relies on experimental features and those get dropped, then the app will be broken unless updated.
17:41 Company: usually those are extra features
17:41 zamundaaa[m]: LTS doesn't ship feature updates of compositors or apps
17:41 Company: that the app has fallback for / can disable
17:41 zamundaaa[m]: as a general rule
17:41 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?
17:42 mclasen: you can't really ship 'the protocols'
17:42 mclasen: you ship compositors and client-side tooling implementing them
17:42 DemiMarie: llyyr: I'm thinking of cases where the compositor and client are out of sync
17:43 llyyr: That's a distro issue, and can happen currently as well even without the experimental folder
17:43 DemiMarie: Old compositor with new flatpak client for example
17:43 DemiMarie: Or old client on newer distro
17:43 Company: that doesn't really happen
17:43 zamundaaa[m]: That problem is independent of experimental protocols
17:43 llyyr: ^
17:43 Company: because clients run without optional protocols anyway
17:44 DemiMarie: Ack
17:44 Company: and we don't do the mandatory stuff as experimental anymore
17:44 DemiMarie: JoshuaAshton: what is wrong with the Wayland WSI?
17:45 bl4ckb0ne: everything? /s
17:45 llyyr: It is explained in the Mesa MR and the linked libSDL PR
17:46 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?
17:48 Company: you need to negotiate supported formats
17:48 Company: and buffer types
17:49 wlb: wayland-protocols Merge request !338 opened by () members: Add mesa as a member https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/338 [governance]
17:50 Company: and there's the whole scale/positioning question, not sure how relevant that is
17:50 vyivel: oh nice
17:50 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.
17:51 DemiMarie: I want to make sure that I take well tested compositor code paths and skip the ones that have hidden bugs.
17:52 kennylevinsen: depends on what you define as rootless - does it do the window management, or does it offload that to a nested compositor?
17:52 DemiMarie: Offloads it
17:53 kennylevinsen: If everything is offloaded, a tiny custom shell that allows arbitrary positioning and focus-less input
17:53 kennylevinsen: Not even that, fullscreen-shell would do the trick
17:54 kennylevinsen: Each nested toplevel just being a subsurface
17:54 DemiMarie: Ah, I misunderstood your question.
17:54 DemiMarie: This is itself a nested compositor.
17:55 mclasen: any examples of what you would want your proxy to shield the host compositor from ?
17:56 DemiMarie: Unexpected client behavior that could cause potentially-exploitable crashes is the main one.
18:00 DemiMarie: Also attempts to cover up things like headerbars.
18:03 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
18:03 kennylevinsen: Better to focus on hardening the host compositor against unexpected client behavior by e.g. fuzzing or proofs
18:07 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.
18:18 DemiMarie: That's really unfortunate. Qubes OS supports multiple X11 window managers and I would rather not lose that when switching to Wayland.
19:20 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)
19:20 wlb: weston Issue #956 opened by () Panel dissappears after blanking https://gitlab.freedesktop.org/wayland/weston/-/issues/956
19:22 d_ed[m]: colinmarc: 6 years ago that could have been useful. Now I'd have to port my toolkit to this magic lib which isn't going to happen.
19:25 colinmarc: do toolkits do WSI directly?
19:27 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
19:28 ManMower: that's a compositor bug, isn't it?
19:29 vyivel: it is
19:29 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
19:29 ManMower: the idea of a malicious compositor intentionally blowing up well written clients isn't really something we put any thought into.
19:30 ManMower: and compositors that are properly written just shouldn't do that.
19:30 DemiMarie: I would write helper functions that do the version check internally and use those to send events.
19:30 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
19:31 colinmarc: * of the ~~entire protocol, * entire protocol~~ the entire interface
19:31 DemiMarie: You can always add new requests and events and declare old ones to be no-ops.
19:32 DemiMarie: That requires a version bump but it is easy to implement on both sides.
19:32 ManMower: xdg-shell is probably a decent example of a protocol that had a long history of experimental implementations before becoming fully usable
19:34 colinmarc: DemiMarie: what if you're just adding an optional argument?
19:38 DemiMarie: colinmarc: No such thing in Wayland.
19:39 DemiMarie: Except for arrays and objects
19:39 colinmarc: yes it is? there are sometimes arguments which are allowed to be null
19:39 DemiMarie: Sorry, strings and objects
19:40 DemiMarie: Those still must be sent on the socket even if null, though.
19:40 colinmarc: explicit optional types are also great, btw, and not hard to write a wire representation for
19:41 DemiMarie: This sounds like a question for Wayland 2.0.
19:41 ManMower: are you saying you want to change a request/event signature between versions?
19:42 colinmarc: DemiMarie: I just read the wire format again (https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format) and I don't see where this is specified. I think you might be talking about the C library?
19:42 DemiMarie: I think that Colin Marc wants something where unexpected fields are ignored and missing fields have a default value.
19:43 colinmarc: yeah, I'm suggesting protobuf-like semantics to make it painless to make small changes
19:43 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
19:43 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
19:44 HW42: X11 our current solution works good enough for the majority of cases
20:00 HW42: *as that being **not** practical
20:01 HW42: would that mean you have trouble to port a remote desktop client with seamless mode support to wayland?
20:05 HW42 [~HW42@000202da.user.oftc.net] requested CTCP PING from #wayland: 1727208350 50853
20:14 HW42: (sorry about that PING, wrong tab completion)
20:14 throwthecheese: There really should be a way to set calibration matrices bypassing libXinput using libinput
20:15 throwthecheese: XOrg has this crappy behavior of not adding my stylus until I touch it to my screen
20:28 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
20:28 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 :(
20:28 Eighth_Doctor: <drakulix[m]> "[@_oftc_vyivel:matrix.org](https..." <- > <@drakulix:catgirl.cloud> [@_oftc_vyivel:matrix.org](https://matrix.to/#/@_oftc_vyivel:matrix.org)I honestly don’t care where cosmic-protocols reside. If any other... (full message at <https://matrix.org/oftc/media/v1/media/download/AeomDdehEN8eIpD7QUC4WL80vaTDDzljxnnhkhAsNWHNnvjwK-F_WhgxC_q7-nX55Wmvx-4S8hHndtbCvaoNRh5CeSJ3B2hwAG1hdHJpeC5vcmcvS2VHeHJpQUl5UERWQWNaUXpMR2xZbkJy>)
20:29 zmike: matrix 🤕
20:30 Consolatis: more like matrix <--> OFTC bridge
20:31 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
20:31 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.
20:31 Sachiel: worked fine for me for decades
20:32 Consolatis: DemiMarie: the bridge could still use the IRC nickname rather than the full matrix address
20:32 Eighth_Doctor: Consolatis: you do a good job giving feedback despite not having any power :)
20:32 Eighth_Doctor: Consolatis: it does if you configure the bridge... I am certainly not Eighth_Doctor on the other side
20:32 DemiMarie: Consolatis: that's indeed a legitimate issue and should be reported as a bug if it has not been already.
20:36 Eighth_Doctor: <emersion> "steamos van run with mesa..." <- I would rather not they did that, since I want these enhancements for Fedora
20:37 Eighth_Doctor: so please let's not suggest things like this
20:37 mclasen: nothing wrong with that suggestion
20:38 Eighth_Doctor: sure there is... it means nobody else gets these improvements
20:38 Eighth_Doctor: we'd never hear about them, or discover them
20:42 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.
20:43 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.
20:44 mclasen: everybody gets to play by the same rules - if you want everybody to benefit, upstream your things properly
20:45 mclasen: of course, its up to mesa developers to make that decision, but that would be my advice
20:46 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?
20:46 ManMower:mumbles something about EGLStreams
20:46 Eighth_Doctor: I kind of see it in a similar light... and seemingly most wayland compositor developers do too
20:47 mclasen: so far I've seen zamundaa's opinion on this
20:47 Eighth_Doctor: I don't know of a single compositor that doesn't implement either private protocols, third party protocols, or both
20:47 mclasen: not sure that counts as most
20:47 mclasen: but anyway, up to mesa
20:47 Eighth_Doctor: sure
20:50 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.
20:51 Eighth_Doctor: IIRC, it's used by MS' weston fork, but that effort was not upstreamed into weston proper
20:51 Eighth_Doctor:should see if he can poke and prod someone about that
20:53 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
20:53 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
20:55 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
20:56 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
20:57 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
20:58 kennylevinsen: and DemiMarie's primary stated purpose of this was isolation from "unexpected client behavior", which would not be granted by such a solution
20:58 kennylevinsen: (such a solution: waypipe)
20:58 HW42: "waypipe requires a full, normal compositor", you mean at the remote side
20:59 HW42: (the less trusted side where the real clients run)
21:00 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)
21:01 kennylevinsen: so it would run on the *trusted* side, at least within my perspective of trust
21:01 HW42: ok, then this doesn't sound like what we want
21:02 kennylevinsen: the compositor is also, in effect, the ultimate source of trust in the Wayland stack, effectively representing the user
21:04 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
21:04 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
21:06 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
21:06 HW42: *rather
21:07 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
21:08 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
21:09 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
21:10 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)
21:10 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)
21:12 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
21:15 kennylevinsen: my comment was about custom protocols, which off-the-shelf compositors will neither speak when nested nor understand from clients
21:15 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
21:18 kennylevinsen: but that's quite different from guarding against blanket "unexpected client behavior"
21:21 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
21:23 kennylevinsen: Then you’re going from Wayland, to custom, to Wayland - what’s in the middle being mostly transparent to either side
21:24 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
21:24 HW42: *what functionality
21:25 ericonr: HW42:
21:25 ericonr: Sorry, ignore
21:29 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.
21:29 kennylevinsen: Otherwise you’re reinventing Wayland but with a different wire format
21:30 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
21:41 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
22:02 JoshuaAshton: colinmarc: that's why the compositor must check for the client version and why the version of objects exists
22:03 Ermine: I guess frog-protocols will become a dependency of mesa if that MR will be merged?
22:04 HW42: kennylevinsen: thanks, I think that mostly answers what DemiMarie was looking for
22:13 Eighth_Doctor: Ermine: yeah, though it shouldn't be a problem since it's available in Arch, Fedora, and openSUSE already
22:14 soreau: it's kinda like saying 'who needs khronos, we got this.'
22:15 soreau: when it might be the only thing controlling the anarchy
22:15 Ermine: Eighth_Doctor: I'm thinking of other distros, namely Alpine and Adélie
22:16 Eighth_Doctor: I think they won't have issues shipping it...
22:16 Eighth_Doctor: it's a build-time dependency only anyway
22:22 llyyr: Ermine: packaging it is trivial
22:25 Ermine: yes, but...
22:39 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.
22:40 Ermine: We have those too