Re: wayland-protocols scope and governance
On 2/21/19 12:10 PM, Simon Ser wrote: > Sorry, these comments feel a bit off-topic here. I'd appreciate if we > could stay focused. Thanks! And, what topic would that be, then, given that the subject of the thread is "wayland-protocols scope and GOVERNANCE"? Or, perhaps you are a non-native English speaker, and the word "governance" has some unconventional connotation for you? Or, maybe "wayland-devel" is not yet ready for introspection? Perhaps another year - or 10 - will be required before certain, more "mature", issues can be broached? ___ 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: [RFC wayland-protocols] Color management protocol
On 12/19/2016 03:04 AM, Pekka Paalanen wrote: > We very deliberately avoid defining any "standard" Wayland interfaces > for configuring a compositor, because every compositor is different. > With X11, you had the one single X server implementation and no other. > On Wayland, every compositor is an individual, just like every X11 > window manager is. > > I do not want to waste time in designing a "standard configuration > interface" when the realistic expectation is that none of the major > DEs' compositor will be implementing it. They already have their own > tailor-made ways. As a case study one could look at the feature set of > xrandr tool. At first glance, that comes across as off-point and shirking responsibility, where Weston boastfully promotes itself as "*the* reference implementation of a Wayland compositor, and a useful compositor in its own right". Where is *Weston's* "pixel perfect" Color Management System? Unless the argument is convincingly made that *nothing* will ever be required from the Wayland protocol in order for any compositor to implement a "pixel perfect" CMS, on its own, then 'deliberately avoid[ing] defining any "standard" Wayland interfaces for configuring a compositor' is just "throwing a monkey wrench" into the conversation. To convincingly make that argument, create the Weston "pixel perfect" CMS, and demonstrate that nothing CMS related was required from the Wayland protocol. What is the design outline of that Wayland-protocol-free CMS? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols] Color management protocol
> as Pekka already pointed out there > are a few constraints that originate in the design decisions of wayland and > are quite different to [those] of X11. We can't change these constraints but > have to find a solution that works well with them: ... I'm more of a bystander to this discussion. It would be really nice to have a shared working document, to follow along, showing 1) a list of Wayland design requirements and constraints for color, and 2) a complete list steps needed to process an image, from source to display, 3) distinguishing issues like color gamut from color encoding. From there, it would be much easier for people to see where "standard interface" lines are being drawn, to see what steps are being handled by the compositor vs an application, to see what steps are automatic and which steps must be manually configured, and to distinguish what *should be* happening, and to see whether anything was "missing", in the processing chain. It is unfortunate that we are all still "stuck in the stone age", exchanging black and white text documents with email, without the tools needed to draw and view nice graphics for block diagrams and such. It is what it is. Still, some clever use of ordered lists can go a long way to creating an understandable sequence with groupings. Would someone knowledgeable be willing to draft a "Wayland Pixel Perfect Color Processing Chain" working document and post it somewhere conspicuously? I'm thinking that someone already knows enough to just rattle this off, from memory? Or, is that document already posted somewhere? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
