On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill <grae...@argyllcms.com> said:
> Carsten Haitzler (The Rasterman) wrote: > > apps should not have exclusive access. we're re-doing the whole horrid > > "install colormap" thing from the x days of 256 color (or > > paletted/colormapped displays). > > It's not quite the same thing in all cases. 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. > 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. 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) 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). for the purposes of calibration, imho a calibration tool should just use drm/kms directly and run in a console outside of wayland. 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). it shouldn't even be needed for pre-calibrated monitors. 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. > Color calibration or "blue light filter" not really - they > are using it as a mechanism for deliberately altering > the color of the whole display so that it affects the appearance > of all other applications. 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. implementing any such protocol for clients is just going back in time to clients messing with key repeat and users wondering why their key repeat is now broken as the client doesn't do it right or colormap installs forcibly being done by clients, or clients messing with screensaver params to try force it to turn off then users complaining that screen blanking is broken and it ends up being some random client they didn't know about, or the screen resolution changing and multi-monitor config being nuked because some dumb client decided to use xf86vidmode to change screen res not knowing that people might have multiple screens configured via xinerama or xrandr and then not even bothering to restore things afterwards either. i've seen many of the outcomes and problems of giving clients direct control over the screen over my decades in x11, and it's a bad thing. we shouldn't repeat the same mistakes. once you open up these doors, they are impossible to close because you now need them for compatibility. > Whether the latter two are in conflict is an interesting question. > > For the purposes of getting a known color behavior they are > in conflict. But then they could also co-operate :- the > "blue light filter" could make use of color management > to implement a specific transform, and do it in such a way > that the white point relative color behavior remains unchanged. > > Cheers, > Graeme Gill. > > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
