Carsten Haitzler wrote:
> On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill <grae...@argyllcms.com> said:
> it involves a screen or set of screens "flashing" between different
> colorspaces. it's much the same kind of effect of ye olde colormap installs.
> not as extreme, but still the entire screen content changing appearance as one
> client is taking control.
That's not a problem if that is what the user is choosing to do.
i.e. they are choosing to have a calibrated screen, or choosing
to use a "blue light filter". Their explicit intention is to
change the appearance of their whole display.
>> A game doing this - yes, it's setting it up just for its
>> private use.
>
> a game should not either. it's a window (surface) within a larger ecosystem
> and
> doesn't own the display. the compositor's job is to ensure that everyone plays
> nice together and to ensure the user has as seamless an experience as
> possible.
Sure - there shouldn't be side effects of something that is for the
use of a single application windows.
> the client can provide colorspace info/lut's alongside a surface/buffer and
> then leave it up to the compositor to implement it or not (alongside perhaps
> the ability to query for such extended features if they exist in the
> compsitor at all - this is a question though of what is the baseline
> featureset we expect from compositors)
Right.
> but it shouldn't CONTROL the output (via any explicit or implicit protocol and
> specs). if the compositor chooses to remap everything on screen so that the
> appearance remains constant based on the focused surface (surface A with
> colorspace X and other surfaces with colorspace Y it can transform to a single
> colrospace based on what the screen is configured to display at the time to
> provide visually a constant experience if possible).
Of course a configuration application should control the compositor. That's
what it's purpose is - to serve the user in exercising their control over their
compositors behavior.
> for the purposes of calibration, imho a calibration tool should just use
> drm/kms directly and run in a console outside of wayland.
Sorry, but that's a total non-starter. Calibration & profiling
tools are applications, and need to run in a normal application
environment to interact with the user. It's like saying that
the user should switch to console only mode to mount a drive
of change a file permission. No-one expects GUI based systems to
operate that way.
> it then owns the
> display. it's not like it's a commonly used tool (likely once on purchase of a
> gpu and/or a monitor).
For those to whom it's vital, it's a commonly used tool. It might
be used once a month, once a week, or needed right now, before some
color critical work is performed. It may be needed to profile
a printer, profile a scanner, or do a soft proof preview.
And switching to some pixel processing pipeline that is
not exactly the same as the composer is exactly the _opposite_
of what is required for assurance that the profile is valid.
A profile should be made with as identical a workflow to
normal as possible.
> it shouldn't even be needed for pre-calibrated monitors.
That's simply not true. Few except very high end monitors come
from the factory with that level of color reproducability.
And even then, anyone doing color critical things can't take
the display manufacturers word - the only way to have confidence
that a display is faithfully emulating a particular colorspace
is to profile it. (And it won't be faithfully emulating anyway
- the black levels will be different to an abstract standard
colorspace.)
> it can calibrate alongside appropriate colorimeter tools and work out some
> profile screen by screen to be given to the compositor in a standard well
> documented format. the compositor then can use that profile to know the true
> color output of that screen and can appropriately adjust content.
Yes, that would be an ICC device profile.
> blue light filter is a "compositor problem". it may or may not farm it off to
> a
> client but it's not something that should be allowed by clients in general -
> these are at best speciality clients that work closely with a compositor, or
> more likely something compositor specific via whatever extension mechanisms
> that compositor supports.
Yes. "Specialty clients" are clients. "Configuration clients" are clients.
Clients work via API's. API's for configuration of the Compositor are
needed to allow the user to configure it the way they want and need.
Cheers,
Graeme Gill.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
