On Mon, 19 Dec 2016 08:04:48 -0700 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? Hi, it sounds like you too are conflating configuration with the public interface to deliver color-managed content. Wayland protocol must grow extensions to let applications tell the compositor what kind of content they provide for color management purposes, and probably also let the applications know which color management features the compositor supports. A very related and useful part of this is letting the applications know what kind of outputs the compositor is using and what their calibration/color profile currently is, but even more importantly, what kind or which color profile/space/... definitions it can handle. That is exactly where Niels started, and he started in the right end of things. The questions to discuss are how do you represent a color profile/whatever and how do you attach one with a wl_surface or a wl_buffer, and how should a compositor process that; what guarantees must a compositor make if it advertises some features; what information does the compositor need to expose; etc. The important bit is that the compositor's global state is read-only in this interface. What I do not want to see as an integral part of this effort is a compositor configuration interface, where a client can *change* how the compositor operates globally, what the color data associated with an output is, or how the hardware is configured. Why? Because it will take literally many years to design and agree on. I don't want to block the design and implementation of the application interface on that. I hope I finally made that crystal clear. Yes, you also need tools and interfaces for calibration and configuration. At this time, calibration needs to be considered on the level of how to present a calibration image, so that you know what a measurement device is measuring. Whether that should be integrated into the normal Wayland interface applications usually use is an open question, but at first hand I would advice against it: it may require resetting the hardware state, which is a global operation, and hence needs to be privileged. It is reasonable to design it as a Wayland interface rather than any other, because it relies on presenting an image through Wayland. Applying compositor configuration OTOH has no reason to be a Wayland interface. You are not presenting anything through it, you are making settings that are at most per-output, and there you do not gain anything from using Wayland as the transport. I bet there will be compositors which are configured by editing a settings file, for instance. I would not want to deny them from implementing any kind of color management support. Every compositor is an individual. If you cannot design the public interface for applications without also designing the configuration interface and requiring everyone to implement both, it will take a very long time to be adopted, if ever. The different DE and compositor projects are not unanimous on how you map a normal window which is a fundamental basic operation of all window systems, how could they ever agree on a configuration interface? Since the people demanding that everything must be application-controlled from the start and that the compositor must do nothing and know nothing are seasoned CMS developers (I presume), I suspect they are trying to force the X11 model of doing CMS upon Wayland. Is it really impossible to separate configuration from content delivery? Niels had an extremely good point that compositors *can* do all the hard stuff too, by using the libraries the CMS experts have written. This is not the X11 where you cannot add these features and dependencies to the X server. Thanks, pq
pgp2Yd8moYe9I.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
