Hi, On Tue, 19 Feb 2019 at 18:36, Drew DeVault <[email protected]> wrote: > On 2019-02-19 4:50 PM, Daniel Stone wrote: > > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) > > This might start getting out of hand, I think. Here's an incomplete list > of clients which use wlr protocols: > > - [...] > > This is just the clients I can think of off the top of my head. Consider > also demo clients, like weston and wlroots clients. There's going to be > a lot of clients! Something I want to avoid is making the criteria for > inclusion in the list subjective, and if we have to decide what makes > GLFW worth including and weston-simple-egl worth excluding, I fear > politics will ensue.
Glibly, I'd probably just categorise the sway* clients in under the Sway/wlroots project, unless they had separate governance, opinions, roadmaps, etc? Similarly, I'm not sure there's much reason for us to separate the toytoolkit and simple-* clients from Weston. wp_* governance has a part to play here as well. Is handing strong-veto rights to every small application the right thing to do? > > My second suggestion is to formalise the 'xdg' namespace. xdg > > extensions have been accepted or rejected by rough consensus between > > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough > > to me, assuming that 'xdg' retains the focus of an integrated (as > > opposed to build-it-yourself) desktop. > > What is the criteria for having a voice in this xdg namespace > "consensus"? This seems a bit opinionated and subjective. Open question! It's a historical fact, for better or worse, that xdg_shell was basically developed and released between those three projects. Something different could definitely happen in future. We had a 'what is XDG actually?' discussion on IRC, and seemed to conclude that xdg_output was a misnomer and didn't belong in the space. That it should actually be things like xdg-shell and xdg-decoration, for app-centric and user-interaction-centric window management, mostly but not exclusively aimed at actual desktops. xdg-shell is obviously usable across non-desktop contexts, but something like ivi_wm/hmi_controller definitely doesn't belong to the XDG namespace. Better wording for the scope is super welcome. One suggestion that came up was applying the same governance to xdg_* as to wp_*, so it would be like 'wp_* for window management'. > > Or Weston hasn't implemented xdg_foreign and probably won't, but I'm > > fine with it existing and being a common extension. On the other hand, > > Weston/Mutter/etc would have very strong opposition to a 'wp_randr' > > extension, and last I saw wlroots would have very strong opposition to > > wp_pointer_gestures. So those wouldn't be wp. > > This makes me wonder: what's the role of Weston in this? As a reference > compositor which isn't designed for end-users, I don't think Weston has > ever been well-positioned to be an influencer on Wayland, but should > rather be a reflection of what Wayland is without its influence. Do you > have any thougths on this? > > In other words, if Weston doesn't want to implement $protocol: so what? I definitely have some thoughts - speaking only for myself, and not for the Weston project as a whole. I'll open up the discussion here since you asked, but it should probably be a separate discussion rather than derailing this. The role Weston plays in the overall Wayland ecosystem has certainly changed over the years, and it's definitely in need of clarification if not adjustment now, but I think Wayland as a whole would be quite different, and net objectively worse, without the roles Weston has played, despite it not having the huge userbase of GNOME/Mutter, nor the proliferation of relatively-less-used-but-strongly-focused projects that wlroots has. One of Weston's goals is to be a reference compositor. As an active implementation, it serves as a useful neutral ground for the rest of the ecosystem: we try to be exhaustively correct in what we do implement, and gets used as a litmus test for clients and compositors both to compare their behaviour against (who's interpreted the spec incorrectly?). We take that responsibility pretty seriously, which places a ceiling on the rate of change as well as the breadth of functionality we can implement. There used to be a rule (observed in all but extremis) that any common protocol had to have a Weston implementation, as the closest analogue we had to a conformance test suite. That was abandoned long ago, since there are some protocols for which it wasn't practical to do so. That was the point beyond which we moved from Weston being _the_ reference compositor for the entire ecosystem, to just being a useful resource. (I get that Weston's README still says 'Weston is the reference implementation of a Wayland compositor' as literally its first words. I'd personally be OK with changing that.) Weston is also useful as a demonstration vehicle for new low-level graphics functionality, particularly for EGL and KMS features. We were the first to do overlay planes, full damage tracking (and now per-plane KMS damage tracking), dmabuf, buffer modifiers, explicit fencing, atomic modesetting, same-CRTC clone mode (AFAIK), aspect-ratio modes, and so on. I'm pretty happy with how that's going, even if we do still have some feature gaps. There are a lot of environments in which having a stable, reliable, efficient, consistently performant, and very capable compositor, is a perfect fit. Not just automotive, but over the years it's landed pretty much everywhere you can think of which has a screen displaying some kind of graphics. The debug protocol and explicit-fencing work we've been pushing forward lately is part of a wider story to make it possible to do end-to-end performance analysis of real workloads running on top of Weston. That helps the people trying to build products with real performance requirements, it helps the developers of all the major toolkits who profile their toolkits on top of Weston (due to the above), and it also helps the wider ecosystem by giving one example of best practice. I take exception to 'not designed for end users' though. desktop-shell has 'full desktop environment' as an anti-goal, but that doesn't discredit the usefulness of the core of Weston, any more than tinywl's deliberately limited scope discredits the usefulness of wlroots. That's literally the reason why we split Weston into libweston-the-core and Weston-the-thing-that-uses-libweston. The fact that the latter and desktop-shell aren't intended to do dynamic output configuration or connect to your WiFi network, doesn't preclude (and has never precluded) from someone building that environment on top of libweston. On the contrary, we explicitly avoided that in desktop-shell, in order to create negative space for others to come and define their own UI rather than making Weston into its own opinionated desktop environment. So far those desktop users of libweston haven't eventuated. I don't think that's anything to do with any of Weston's aims above; from what I've seen, it's mostly because libweston is very underdocumented, has some corners where we opted for a spiky-but-capable rather than a friendly-but-easy API design, has some parts where we made the cut between Weston and libweston at the wrong place, and some parts which have clearly never been used by more than one implementation. These are technical issues we can fix without compromising any of those aims above. (There's also the community issue, in that it was unnecessarily difficult to approach, communicate with, and contribute to Weston as a project: something we've worked really hard on fixing over the past year.) So yes, I do think Weston has value in the ecosystem. As a personal contributor who spends his free time on it, if the Wayland project decided as a whole that Weston was required to have no opinion or influence on the ecosystem and instead just serve as a note for whatever everyone else came up with, I would just walk away from Weston. As a Wayland developer, I'd argue against that decision, since I think Wayland as a whole would be worse for it. With my Collabora hat on, rather than invest our own time into the ongoing health and development of Weston, I'd cut out the middle man and just invest our time into writing documentation instead. As a concrete example, most of the rest of the Wayland ecosystem has decided to make text layout and image decoding block the compositor's main presentation loop. Weston has deliberately avoided this, in order to achieve the goals listed above, and it's been successful in that. desktop-shell provides an example to others of using intent-declarative private protocol to achieve this. People can follow that example if they want to; there are plenty of examples of people doing the opposite as well, which is totally fine. If the conclusion of what you're saying is that Weston could not serve as a unique counter-example - the wider ecosystem has decided that delegating surface picking is a good idea and suddenly you can't do overlay planes - then Weston becomes useless to its actual end users. If those end users fall away, so do the developers, and the project. (Who would want to actually work on that ... ?) But why should Weston cripple itself in order to create this negative space for wlroots or Mutter or Smithay or whatever? I'm happy to clean up the README to reflect reality. One of the side effects of creating this protocol documentation site really should be an update of the Wayland site as a whole to reflect the actual reality of Wayland as a project in 2019, including better and more accessible documentation, linking to the various environments and implementations (including linking to a separate Weston site), and, y'know, not claiming that Weston's X11 backend uses DRI2. The entire site describes a project which has long since moved on a long way since it was written - including the role that Weston plays. > How do/should the gatekeepers of Weston make these decisions? Same way as the wlroots or Mutter maintainers do ... ? Make a judgement on how the protocol fits with the aims and realities of Weston as a project. A randr protocol as has been proposed before does not meet that test (same for Mutter). Maybe a libweston user would want to implement it. Good for them; they're completely free to do so. That to me says that listing that protocol under a namespace of 'everyone agrees on it, and it's a good protocol you should use as it will work most everywhere' is a bad idea. If you came out and said 'wlroots will never implement idle-inhibit because $reasons', that would suggest it shouldn't be listed in that 'uncontroversial and widespread' namespace either. What I had in mind was something like xdg_shell, where a short and recognisable prefix would set an expectation that the protocol was in widespread use; that authors of new compositors should implement it to be maximally compatible, and clients should write to it and be able to expect it mostly works. Maybe, as Pekka said, that isn't workable and we should scrap the idea of agreed-upon prefixes and leave it a free-for-all. > > Bikeshedding the prefix to use [for vetoed but still relevant > > protocols] would be welcome, as I don't have any good suggestions > > right now. > > xdg? > > I think gatekeeping the xdg namespace is going to allow a lot of the > frustrating politics to thrive even with these changes, and it is a nice > namespace for defining these standards. XDG is already overloaded enough that I'd like not to add 'stuff some people use but others feel very strongly about not using' to it. Some people also interpret XDG to mean 'freedesktop.org Certified Seal of Approval™', which is ... sort of the opposite of that. > > Once we've established and codified these ground rules - with a > > document along the lines of Wayland's CONTRIBUTING.md - we can open up > > commit access to wayland-protocols, so we're not so reliant on a > > couple of arbitrary gatekeepers. Obviously this would be done with the > > expectation that those ground rules are followed - don't post a wp_ > > extension on a Sunday morning and then commit it in the evening with a > > couple of +1s because no-one objected - but we're all reasonable > > adults, and can treat each other reasonably without having to enforce > > ACLs. > > > > Does anyone have any thoughts or suggestions here? Is this a good > > aspiration? Is it the best way of achieving that aspiration? > > +1 > > I don't see commit access as a magic equalizer, fwiw. I don't mind > sending a patch along and letting someone else integrate it so long as > they're following well-defined policies and not operating under their > own agenda. Right. On the other hand, I also don't want to have to gatekeep development of protocols I have no interest in (even if it is just clicky busywork), and even protocols I do have an interest in. If we're lowering the barrier to entry and trying to raise our level of inclusion, we might as well deal with the bus factor whilst we're here. > Another thing I'd like to clarify is the process of agreeing on the > appropriate prefix for a protocol. Perhaps there's an experimental_ or > draft_ namespace which has a near-zero barrier to entry (just add your > implementation to the list), and then you can separately make your case > for adopting it into another namespace. During the draft step you can > pitch your protocol to interested parties, write implementations, and so > on, which strengthens the case for including it in some namespace. > > Under this process, the xdg and wp and whatever else namespaces reflect > reality, and each protocol there is known to have the support of at > least a few implementations - rather than reflecting that at some point > some number of people agreed it would be a good idea, and then maybe or > maybe didn't write implementations. To be honest, that sounds a lot like the development process we have already. If something is expected to be under heavy development and potentially need a lot of rework after implementation, then it can just live in a branch and people can pull it from the MR or whatever as they develop it in their (presumably also not merged) compositors or clients. I think the 'z' prefix and general unstable versioning rules work well here. If multiple people have implemented a protocol and are sharing it, then (taking 'ext' as a strawman for not-wp-but-not-single-project-either) it would be zext_redshift_v1. If single projects wanted to push something, then they could push it under their own namespace, e.g. zmutter_animation_control_v1, but at that point it's not really clear what benefit there is to it being in wayland-protocols master. At that stage of development, it's probably going to be more of a hindrance having to observe the versioning and stability rules. Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
