[PATCH weston v5 09/36] cms-colord: find a good head

[Pekka Paalanen]

On Thu, 1 Feb 2018 22:10:33 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
> 
> On 1 February 2018 at 22:00, Derek Foreman <derekf at osg.samsung.com> wrote:
> > On 2017-12-14 05:40 AM, Pekka Paalanen wrote:  
> >> The 'head' member of 'struct weston_output' is going to go unused and
> >> then disappear, so stop using it and find a head from the proper list.
> >>
> >> However, this leaves a problem in cms-colord: if you have multiple
> >> monitors driver with the same CRTC, what do you say to the color
> >> management system? The monitors could be different, but all the color
> >> LUTs etc. are in the CRTC and are shared, as is the framebuffer.
> >>
> >> Do the simple hack here and just use whatever head happens to be the
> >> first in the list.  
> >
> > I am a complete non-expert in this area, so if I'm making no sense feel free
> > to tell me to shut up...
> >
> > I think if someone's going through the effort to properly setup color
> > management, then we can't use cloned heads off a single CRTC?
> >
> > We should probably disallow a CRTCs to drive multiple heads if two or more
> > of those heads have differing color profiles?
> >
> > If I went to the trouble of calibrating two displays, I would probably be
> > extremely surprised to see them looking different with clone mode enabled.  
> 
> Yeah, what Derek said. I think non-homogeneous colour properties when
> colour management is enabled, should be cause to unclone. That being
> said, it's a niche enough usecase that I'd be comfortable landing it
> with documentation that it was a known shortcoming. I'd be super
> comfortable landing it if we also had an output configuration tweak we
> could use to force non-clone mode, or really even just a simple
> out-of-tree patch (or environment variable, a la atomic?) that allows
> people to work around it easily enough by disabling clones.

Hi,

I agree with Derek's suggestion that we should check color properties
and fail the shared-CRTC cloning, and with Daniel that we could just
document this. I'm not sure what the "output configuration tweak"
refers to. Do you mean an option that would just disable shared-CRTC
cloning?

We have Weston that handles all option parsing, and Weston also does
the decision to use or not use shared-CRTC cloning by how it attaches
heads to outputs. Libweston will not try shared-CRTC cloning unless
explicitly told to, and it will not transparently fall back to
something else. After the complete clone mode series, which will not
include independent-CRTC cloning support, the option to disable
shared-CRTC cloning would be equivalent to a weston.ini that does not
configure cloning at all.

However, the weston.ini syntax as is does not differentiate between
shared-CRTC and independent-CRTC cloning. My intention is that Weston
(not libweston) attemps shared-CRTC cloning and falls back to
independent-CRTC cloning.

For the cms-colord plugin to be able to veto shared-CRTC cloning we
would need libweston infrastructure work to either offer plugins a veto
API or make libweston core aware of color profiles. An alternative
would be to have Weston query the color management plugin directly if
heads are compatible for shared-CRTC mode.

One more idea coming to mind is that the "same-as" directive in
weston.ini could refer to either exclusively shared-CRTC clone mode or
shared-CRTC with fallback to independent-CRTC mode, and we could use a
hypothetical future output layout configuration directives to force
independent-CRTC mode by defining two outputs to show the same area of
the desktop.

Given that, what would you recommend for now?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180202/9b2255aa/attachment.sig>