On Mon, Dec 19, 2016 at 7:04 AM, James Feeney <ja...@nurealm.net> wrote: > 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?
I can certainly see where you're coming from, as I too had similar thoughts when getting my feet wet with with protocol design for tablet input events. What it basically comes down to is that standardized Wayland protocols are intended for providing features to "general purpose" applications. Standardized protocols are not generally used for configuring compositors for multiple reasons, e.g. recognizing that not every compositor will want to offer the same configuration options in the same way (read: feature-creep of configuration interfaces with ever-more-niche options that only matter to single compositors), and concerns about random applications changing settings (read: sensitive/priviliged operations and applications "fighting" each other to apply conflicting configs). There is no "standard configuration interface" for something even so basic as configuring input devices. It sure feels like shirking responsibility, but its a conscious design decision to try and avoid some of the pain points that we lived with in X. Its possible to separate concerns of usage from configuration without "throwing a monkey wrench" into the conversation. Its just necessary to be mindful that defining (standard) Wayland interfaces is not necessarily always the appropriate design decision. I'm just a hobbyist photographer whose done casual reading about color management and use a second-hand colorimeter and can't wait to see some color management come to Wayland. But it will be necessary to figure out exactly how to deal with its complexities in a way that is compatible with Wayland's fundamental design decisions. Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours.... _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
