Re: wayland-protocols scope and governance
On 2019-02-21 4:00 PM, Pekka Paalanen wrote: > Let's forget about the prefixes or namespaces indicating anything about > endorsement or acceptance. I don't think using prefixes/namespaces for acceptance/blessedness is going to be a good idea, but I do think defining some namespaces and a scope for the protocols in them is useful. We'll want a catch-all namespace (I like Daniel's "ext" suggestion) for stuff that doesn't fit nicely to avoid the political problems of a protocol with nowhere to go. Part of the problem so far has been that the scope for each prefix is poorly defined, so when gatekeepers appeal to that scope it has been frustrating in the past, especially without any other namespace for a protocol looking for a home to go. Fixing those two issues would do a lot. > The benefit is that we avoid almost all of the design-political > debates. The only policy question left to answer is what kind of > extensions are eligible to wayland-protocols at all, and there I think > we could be very lenient: anything that has a prospect of being used by > more than one software project. This seems reasonable, though we might as well clarify that there ought to be a least one client and one server implementation, ideally under the governance of different projects. > - Look at who the maintainers for the extension are, if you know their > personal reputation. > > - Additionally, if wanted, we could even add "reviewed-by" entries to > the extension meta data in addition to the maintainer entries, if > people want to promote their endorsement of an extension. Are people more useful than projects in this case? I couldn't name all of the GNOME developers and I'm sure you couldn't name all of the wlroots developers - but a protocol endorsed by GNOME or wlroots as a whole implies a consensus among those people and conveys practical information about the usefulness of a protocol more efficiently. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On 2019-02-21 6:11 PM, Jonas Ådahl wrote: > IMHO we should choose one or the other, not some combination where > Gitlab sends E-mails to the mailing list for merge requests, as this > would mean we'd end up with multiple diverging versions of the same > discussion thread. fwiw I think a mailing list is more conducive to the discussions which will need to happen in the course of participating in this effort, at least if a space to discuss protocol design is still in scope for this effort (and I hope it is). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Thursday, February 21, 2019 7:36 PM, James Feeney wrote: > As an outside observer, and still cheering for Wayland, I've often > felt inclined to rant about the focus and management of the "Wayland > Project", or perhaps, its lack thereof. […] Sorry, these comments feel a bit off-topic here. I'd appreciate if we could stay focused. Thanks! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On 2/21/19 8:47 AM, Daniel Stone wrote: > 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. As an outside observer, and still cheering for Wayland, I've often felt inclined to rant about the focus and management of the "Wayland Project", or perhaps, its lack thereof. To put this in perspective, let me remind, that the "Initial Release" of the "Wayland Protocol" is shown at Wikipedia as "30 September 2008". So now, after over 10 YEARS of intense development, and to this day in 2019, *still*, no really usable Wayland Desktop Compositor exists. Consider - Weston is excused as a "toy"; Mutter still cannot function without XWayland, with the position that "yeah, someday we should fix that"; kwin_wayland still cannot function *with* XWayland, with the position "won't fix"; sway is a tiling-only compositor; enlightenment cannot handle multiple screens - and on and on, with limited functionality. Worse, it appears that none of the developers have focused upon some of the *most basic* functionality that an end user would require for day-to-day use. "Cut and Paste" *still* requires too much extra work. There is *still* no "xrandr" replacement. "Color Management" seems to be an "afterthought". There is *still* no standard for networking Wayland client/server. What's actually been going on for 10 years? On top of that, over the years, certain developers have been actively hostile toward proposed contributions to address these missing bits of functionality. As a group, the Wayland Project might also do better at playing well with others. Notoriously, the Wayland Group alienated the Mir Group. How did that work out for everyone? So, as long as "you all" want to play together in a "private sandbox", hey, that's your business, and not my place to criticize. But, if instead, the desire is to produce some kind of "Community Desktop" software for the benefit of more than just this specialized group of graphics software engineers - well, it would be a really good idea to "step up the game" and change the project focus, to directly address "real world" expectations from potential users. In particular, I would also remind of Eric Raymond's "The Cathedral and the Bazaar". Somewhere, not obviously publicized, the Wayland Developers have chosen the "Cathedral" approach to development as the best way forward. Maybe, instead, reflect upon a possible alternative, "release early and often, delegate everything you can, be open to the point of promiscuity". It could be worth another read. All in all, I really appreciate Daniel raising this issue. Just saying... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On 2019-02-21 3:47 PM, Daniel Stone wrote: > 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. This concept is somewhat alien to the all-in-one compositors like GNOME and Weston, but the sway* clients are portable between compositors. Users of Wayfire, Way Cooler, Waymonad, etc - are all able to, and do use, swaylock, swayidle, and so on. So is the list about structured governance, or about discovering clients which will work on your compositor if you implement $protocol? For example, I would not include swaybar, which depends on sway-specific interfaces and doesn't work without them. > wp_* governance has a part to play here as well. Is handing > strong-veto rights to every small application the right thing to do? If we're establishing a table, it may make sense to give wlroots as a whole a seat at that table. wlroots is where the implementation lives, after all, for all of the compositors who use it. We already kind of do this with wlr-protocols. > > 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. > > One suggestion that came up was applying the same governance to xdg_* > as to wp_*, so it would be like 'wp_* for window management'. So there are two issues: the governance model of xdg, and the scope of xdg. No objections to governing it the same way as wp, so long as we make sure everyone has a voice. The scope also seems fine, though if xdg-shell is meant to be useful outside of desktops as you said, it's probably better suited for wp. Since it's a stable protocol we'll probably have to acknowledge that as an artifact of the past. > I definitely have some thoughts [on Weston] %< I apologise if I came across as disparaging to Weston, that wasn't my goal. I too have found Weston useful as a reference and have a lot to thank it for. I was trying to derive Weston's role in governance from its goals, assuming these goals: 1. Be the reference Wayland compositor 2. Be a useful compositor in its own right 3. Be the basis for new desktop Wayland compositors via libweston Sometimes these goals conflict, and Weston's role in governance might change depending on which of these goals you're focusing on. It might not be desirable to be a "political" entity to best fulfill goal #1. Fulfilling goal #3 effectively might be best served by deferring judgement to the compositors which are based on libweston. Goal #2 may politically conflict with goals #1 and #3. And so on. Daniel and I clarified this off-list, so I'll omit the longer explanation and we'll just move foward under the assumption that Weston ought to have as much of a role in Wayland governance as anyone else. > 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. Agreed-upon prefixes is probably a good idea, assuming we can find agreement. > > 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. The frustrating problem is that xdg-shell exists and is stable and is called xdg-shell. We should probably rename xdg-output, by the way, before it becomes stable. > 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. Fair point. Once we establish a role for each prefix, then it might be good to establish a group of stakeholders with commit access and a gentleman's agreement between them to follow the rules we set forth. As for membership in this group: I propose inviting a diverse group of existing stakeholders, including at least the people we've already talked about (let's add Smithay to that, too). Then new members can be added by invitation from an existing member. If we have a large and diverse enough membership, I'm less concerned about gatekeeping. If you just have to convince at least one member to sponsor your membership, then that's should be easy enough. > To be hon
Re: wayland-protocols scope and governance
On Thu, Feb 21, 2019 at 11:47:13AM -0500, Mike Blumenkrantz wrote: > Hello, > > On Thu, Feb 21, 2019 at 10:47 AM Daniel Stone wrote: > > > > > 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. > > > > > Speaking on an entirely personal level (i.e., unrelated to any project or > employer) and as someone who has spent an amount of time writing both > compositors and clients using Wayland protocols--and also writing those > protocols, I found this to be very accurate. My ability to successfully > implement protocols in compositors and clients has benefited tremendously > over the years from the existence of Weston and its clients, even despite > their noted shortcomings. I'll also go a step further and challenge anyone > who has done similar work to deny having similarly benefited from Weston. I too have spent years working on various sides of the Wayland world and can only repeat the usefullness of weston; the library, toy desktop envirnonment and sample clients. Both for help with understanding interaction with lower level APIs, and for having something to compare a protocol implementation with, and test clients on. I think the focus on correctness, both regarding protocol implementation and overall anchitecture (e.g. avoiding any UI rendering in the main thread/process), as well as show casing various KMS features, and anti-focus of end user facing features is key here. > > If anything, I think devoting more time and energy to improving Weston and > underlying layers would only serve to help the Wayland-using community. > Better documentation and better reference code lowers barriers to entry and > improves the ecosystem: this is something I know all too well from some of > the projects that I've worked on. Agreed. Jonas > > > Regards, > Mike > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Tue, Feb 19, 2019 at 04:50:27PM +, Daniel Stone wrote: > Hi all, > I'd like to open up a discussion on enlarging wayland-protocols to a > wider audience, with a better definition of what it contains. > > Currently, wayland-protocols is a relatively small set of protocols > which were either grandfathered in from Weston, or a semi-opinionated > set of protocols that someone thinks is 'good'. > > The original intent was to provide a set of 'blessed' desktop > protocols which 'everyone' would probably implement in order to > provide a coherent Wayland environment. To some extent - xdg-shell, > dmabuf, xdg-output, viewporter - this succeeded. For some others, it > failed badly - the input protocols no-one likes or has implemented, > necessitating Dorota's rewrite. > > The elephant in the room is extensions like layer-shell and some of > the related extensions to build a desktop environment from a set of > disparate clients using generic APIs. Personally I think the > experience of X11 shows it's only designing for pain, and this is the > general position of wayland-protocols at the moment. But on the other > hand, those protocols aren't going away, they are in use, and having > them developed in a separate siloed community is doing us all a > disservice, since neither hand fully knows what the other is doing. > Even if we don't agree on the fundamentals of the protocol, we could > at least discuss it and try to point out some pitfalls and make some > suggestions for improvement. > > A related issue is that it's hard for both application and compositor > authors to figure out what to do. There is no good 'big picture' on > how these protocols fit together, nor can people figure out which of > the competing proposals they should be using if they want to write an > application running on a given compositor, nor can compositor authors > figure out what apps want them to support. Depending on who happens to > be paying attention to the particular forum the question is asked, > they might get very different answers, depending on the point of view > of who answers. > > My first, hopefully uncontroversial, suggestion: introduce a list of > compositors / compositor frameworks, as well as clients / client > frameworks, and which protocols they use and support. This would help > both application and compositor authors figure out where they should > invest time and effort. I suggest that we keep this lightweight: have > a registry of compositors / compositor frameworks / toolkits / > clients, each with a couple of named people who can speak > authoritatively for that project. > > We could then allow each project to declare its support (or otherwise) > for any extension: will not ever implement, implementation not > planned, no opinion or N/A, implementation planned, implemented but > use not recommended (or limited/stubbed), implemented and recommended. > This list would be machine-parseable (XML, JSON, YAML, whatever is > easiest to fit), with a GitLab CI pipeline used to generate a > https://wayland.freedesktop.org/protocols/ website on every push, > which gave both a per-extension and a per-project support table. And > some more readable docs. I think this would be a really good entry > point and clear up a lot of confusion. > > As a strawman list of projects to begin with (I'm sure there are others): > - compositors and compositor frameworks: Chromium (Exosphere), > Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots > - toolkits: EFL, GTK, Qt > - media: GStreamer, Kodi, VLC, XBMC > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) I too agree that this is a good idea. I'm not too sure about the usefulness listing all applications that may use some protocol or another. Might make more sense to keep such a list in a less formal place like a wiki page on gitlab. For a compositor protocol support matrix, I see the value as much higher. > > 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. The IVI namespace would > similarly be delegated to automotive people, and maybe we could > delegate the layer_ namespace to those developers as well. > > My third suggestion is to formalise the 'wp' namespace, as core > extensions that everyone can agree on. It doesn't mean everyone needs > to implement them, but at least not have active opposition. For > example, Mutter hadn't implemented wp_viewporter for the longest time, > but also had no opposition to it being implemented - which wouldn't > block it being a 'wp' protocol. 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
Re: wayland-protocols scope and governance
Hello, On Thu, Feb 21, 2019 at 10:47 AM Daniel Stone wrote: > > 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. > > Speaking on an entirely personal level (i.e., unrelated to any project or employer) and as someone who has spent an amount of time writing both compositors and clients using Wayland protocols--and also writing those protocols, I found this to be very accurate. My ability to successfully implement protocols in compositors and clients has benefited tremendously over the years from the existence of Weston and its clients, even despite their noted shortcomings. I'll also go a step further and challenge anyone who has done similar work to deny having similarly benefited from Weston. If anything, I think devoting more time and energy to improving Weston and underlying layers would only serve to help the Wayland-using community. Better documentation and better reference code lowers barriers to entry and improves the ecosystem: this is something I know all too well from some of the projects that I've worked on. Regards, Mike ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
Hi, On Tue, 19 Feb 2019 at 18:36, Drew DeVault 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, particular
Re: wayland-protocols scope and governance
On Thu, 21 Feb 2019 09:05:26 -0500 Drew DeVault wrote: > On 2019-02-21 2:53 PM, Pekka Paalanen wrote: > > the list seems purely informative. Is it actually bad if it ends up > > containing hundreds of entries? If someone actually wants their > > individual apps listed, why not? > > You're right, I retract my concerns about the list being unwieldy. I was > thinking about this in terms of the maintainers of the protocols > updating the list, but naturally it makes more sense for the maintainers > of the clients to add themselves. Hi Drew, yes, indeed. I'd hope that the maintainers of the software (implementation) in question would send the updates. Of course, anyone could post updates by pointing to code or commits that implement or remove support, I think. Thanks, pq pgpR_BgPepp0Y.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On 2019-02-21 2:53 PM, Pekka Paalanen wrote: > the list seems purely informative. Is it actually bad if it ends up > containing hundreds of entries? If someone actually wants their > individual apps listed, why not? You're right, I retract my concerns about the list being unwieldy. I was thinking about this in terms of the maintainers of the protocols updating the list, but naturally it makes more sense for the maintainers of the clients to add themselves. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Tue, 19 Feb 2019 16:50:27 + Daniel Stone wrote: > Hi all, > I'd like to open up a discussion on enlarging wayland-protocols to a > wider audience, with a better definition of what it contains. > > Currently, wayland-protocols is a relatively small set of protocols > which were either grandfathered in from Weston, or a semi-opinionated > set of protocols that someone thinks is 'good'. > > The original intent was to provide a set of 'blessed' desktop > protocols which 'everyone' would probably implement in order to > provide a coherent Wayland environment. To some extent - xdg-shell, > dmabuf, xdg-output, viewporter - this succeeded. For some others, it > failed badly - the input protocols no-one likes or has implemented, > necessitating Dorota's rewrite. > > The elephant in the room is extensions like layer-shell and some of > the related extensions to build a desktop environment from a set of > disparate clients using generic APIs. Personally I think the > experience of X11 shows it's only designing for pain, and this is the > general position of wayland-protocols at the moment. But on the other > hand, those protocols aren't going away, they are in use, and having > them developed in a separate siloed community is doing us all a > disservice, since neither hand fully knows what the other is doing. > Even if we don't agree on the fundamentals of the protocol, we could > at least discuss it and try to point out some pitfalls and make some > suggestions for improvement. > > A related issue is that it's hard for both application and compositor > authors to figure out what to do. There is no good 'big picture' on > how these protocols fit together, nor can people figure out which of > the competing proposals they should be using if they want to write an > application running on a given compositor, nor can compositor authors > figure out what apps want them to support. Depending on who happens to > be paying attention to the particular forum the question is asked, > they might get very different answers, depending on the point of view > of who answers. > > My first, hopefully uncontroversial, suggestion: introduce a list of > compositors / compositor frameworks, as well as clients / client > frameworks, and which protocols they use and support. This would help > both application and compositor authors figure out where they should > invest time and effort. I suggest that we keep this lightweight: have > a registry of compositors / compositor frameworks / toolkits / > clients, each with a couple of named people who can speak > authoritatively for that project. > > We could then allow each project to declare its support (or otherwise) > for any extension: will not ever implement, implementation not > planned, no opinion or N/A, implementation planned, implemented but > use not recommended (or limited/stubbed), implemented and recommended. > This list would be machine-parseable (XML, JSON, YAML, whatever is > easiest to fit), with a GitLab CI pipeline used to generate a > https://wayland.freedesktop.org/protocols/ website on every push, > which gave both a per-extension and a per-project support table. And > some more readable docs. I think this would be a really good entry > point and clear up a lot of confusion. > > As a strawman list of projects to begin with (I'm sure there are others): > - compositors and compositor frameworks: Chromium (Exosphere), > Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots > - toolkits: EFL, GTK, Qt > - media: GStreamer, Kodi, VLC, XBMC > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) Hi Daniel, I wholeheartedly agree on the problem statement and the first suggestion. It is as important if not even more to list which software components have rejected a certain Wayland extension than it is to list which extensions are supported. > 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. The IVI namespace would > similarly be delegated to automotive people, and maybe we could > delegate the layer_ namespace to those developers as well. > > My third suggestion is to formalise the 'wp' namespace, as core > extensions that everyone can agree on. It doesn't mean everyone needs > to implement them, but at least not have active opposition. For > example, Mutter hadn't implemented wp_viewporter for the longest time, > but also had no opposition to it being implemented - which wouldn't > block it being a 'wp' protocol. 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
Re: wayland-protocols scope and governance
On Tue, 19 Feb 2019 13:36:51 -0500 Drew DeVault wrote: > This is a great plan, Daniel, thank you for taking the time to write it > up and help push this problem towards a solution. > > On 2019-02-19 4:50 PM, Daniel Stone wrote: > > My first, hopefully uncontroversial, suggestion: introduce a list of > > compositors / compositor frameworks, as well as clients / client > > frameworks, and which protocols they use and support. This would help > > both application and compositor authors figure out where they should > > invest time and effort. I suggest that we keep this lightweight: have > > a registry of compositors / compositor frameworks / toolkits / > > clients, each with a couple of named people who can speak > > authoritatively for that project. > > > > As a strawman list of projects to begin with (I'm sure there are others): > > - compositors and compositor frameworks: Chromium (Exosphere), > > Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots > > Sway & wlroots probably shouldn't be separate, but it might be useful to > link to the list of wlroots-based projects from the compatability page: > > https://github.com/swaywm/wlroots/wiki/Projects-which-use-wlroots > > These projects rarely, if ever, implement protocols themselves, opting > instead to implement them in wlroots and share the functionality with > everyone else. > > > - toolkits: EFL, GTK, Qt > > GLFW, SDL > > > - media: GStreamer, Kodi, VLC, XBMC > > mpv > > > - 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: > > - mako > - slurp > - grim > - wl-stream > - xdg-desktop-portal-wlr > - swaylock > - swayidle > - swaybg (soon) > - waybar > - jaybar > - phosh > - virtboard > - bemenu > > 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. Hi, the list seems purely informative. Is it actually bad if it ends up containing hundreds of entries? If someone actually wants their individual apps listed, why not? A big list may be hard to search, so we could categorize it into e.g. toolkits vs. individual clients when generating the web pages, so that people can get a good overview by just looking at the toolkit list. If people don't keep the software vs. extensions status updated, it only means there will be lots of "unknown" as to what the attitude of a given piece of software is towards a given Wayland extension. When we generate various indices for the web site, "unknown" entries could be skipped. To me the main point of such list would be to list a bunch of software that already supports certain Wayland extensions, but also importantly list which software projects have refused to support some other extensions. Both aspects are very important when a developer of an application or a compositor is contemplating on using specific extensions. By no means should the list be exhaustive, just the most used software plus any that wants in on the list, IMO. Thanks, pq pgpXbOEcUqaFh.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
