Hi, could you keep the CC list intact, please.
On Mon, 19 Dec 2016 12:37:14 +1100 Graeme Gill <grae...@argyllcms.com> wrote: > Pekka Paalanen wrote: > > On Wed, 14 Dec 2016 18:49:14 +1100 > > Graeme Gill <grae...@argyllcms.com> wrote: > > >> Please read my earlier posts. No (sane) compositor can implement CMM > >> capabilities to a color critical applications requirements, > >> so color management without any participation of a compositor > >> is a core requirement. > > > that is a very strange requirement, and architecturally it is a big > > step backwards. > > Since Wayland doesn't currently implement any color management support, > I'm not following how it can be a step backwards. It is step towards "clients are in control and the compositor does not know what is happening". That is, a step towards X11 design and away from Wayland design principles. > > It > > may have been so with X11 where any client can change any display > > setting any time it wants, but I cannot see that happening on Wayland. > > Wayland is useless unless there is a way to manage it. Which means > that it should have channels for administrative tools to configure it. Indeed: Administrative tools. These are part of the compositor or the desktop environment distribution. They have the privileges to configure the compositor. However, in this thread we are talking about arbitrary applications, not administrative tools. Administrative tools must always be written to interface with the compositor, they cannot go changing things behind the compositor, because then the compositor will lose track of the setting and malfunction will happen. 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. If you want a standard interface, you have to get the buy-in from the major DE projects first. One can write a protocol spec and throw it into wayland-protocols, but whether anyone will implement it is another matter. > > If the pixels go through a display server, you have no choice but to > > trust the display server to do the right thing. So the real question > > is: "How do you let the compositor do the right thing?" > > Not: "How do I bypass the compositor?" > > I didn't ask to bypass the compositor - you are the one assuming that. > > I merely asked that core color management provide a means hat allows the > application to provide display colorspace values, and that the compositor > not mess with them. That is one of the things you said you want. You also said that: "Which is why protocols for controlling the hardware should ideally go via Wayland, so that applications who's job is to setup that hardware can work." Those are two very very different things. The first one I agree. The second one I strongly object unless it originates from more than one DE project and is kept non-essential for correct operation. Please, do not conflate them. > > - You do not know which parts of a window are shown on which outputs. > > Right. So that information needs to be communicated to the application, > just like it currently is on systems like X11, OS X and MSWin. No, it will not. The application cannot keep up with window moves re-rendering the regions and the compositor cannot wait for the application to catch up. Adding features that cannot be implemented without introducing glitches was fine with X11, but it is not ok in Wayland. In this case, it is possible to achieve the goal without introducing such glitches. > > - Calibration (i.e. modifying compositor configuration) > > No, calibration in this context is setting the CRTC per channel > lookup tables (RAMDAC contents). That *is* compositor configuration. There is no other entity to maintain it. See the reference to libinput configuration below as an example of another similar case. > > must > > necessarily be a separate interface from the ones used by > > applications that only want to present color-managed content. > > Sure. Which is what I suggested. You have mentioned configuration being separate maybe once or twice, yet in every turn you have been promoting configuration as a necessary part in conjuction with the public color-managed content interfaces, conflating the two into one, hence my objection. > > Conflating it all into a single interface will cause problems with > > privilege separation and encourage usage patterns where different > > applications cannot work at the same time because they will be > > fighting over who gets to set the current configuration. > > Please suggest how to organize it then. I have looked through > the Wayland documentation, and didn't spot any discussion on > how privileged management operations are authorized or > conveyed. Splitting these things up may make for a lot > of extensions though. Seems simpler to privileged certain > operations. Extensions are extremely cheap. It is much harder to have a privileged operation inside an otherwise public interface, than making a whole new different interface for the privileged actions. The first step would be to start talking about them as completely separate and independent things. You do not need to design the configuration interfaces at the same time with the interface that applications use to provide color-managed content. They should be very much orthogonal, not the least because you cannot except any compositor to implement the configuration interface. However, a common standard interface for describing color-managed content and the compositor capabilities is important to have. > > Applications have no right to be configuring *anything* in a desktop > > compositor. > > So how is a Wayland desktop managed then ? By magic ? By the afore-mentioned administrative tools, that most often do not use Wayland to talk to the compositor, because they already have other means (that are not X11 either). > > It is usually reserved for the desktop > > environment's configuration utilities that the user will be using > > manually. > > So how does one write a Wayland based desktop configuration > utility/application > in a way that is not dependent on the particular operating system > environment or compositor ? That's a part of the general question: How do you write a desktop environment configuration utility that works in KDE, GNOME and Enlightement? I believe the answer which has been proven over the many years is: either you write one for each, or you don't. A related example for a different sub-system: http://who-t.blogspot.fi/2016/03/why-libinput-does-not-have.html Whenever libinput gets a new feature or setting, all compositors need to add code to support it. Why you cannot have a configuration interface directly into libinput to avoid waiting for compositors to implement the support is explained in that blog. The same reasons apply here. > As I've pointed out, expecting every such application writer > to write N versions of it for every possible such operating > system environment is a non starter, and the cracks will soon start > to show with remote versions of Wayland. The whole point of creating a > protocol such as Wayland is to provide a common API that can be used > by all applications that are intended to run on Wayland. Indeed, that is the job of the desktop environment developers, not the application writers. The times when you could just bypass the DE when something didn't work are behind us. The key to success here is to completely decouple configuration from application usage, and concentrate on the application usage which can be standardised. Thanks, pq
pgpdUhu0kBUVs.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel