On Thu, 1 Feb 2018 22:10:33 +0000 Daniel Stone <dan...@fooishbar.org> wrote:
> Hi, > > On 1 February 2018 at 22:00, Derek Foreman <der...@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
pgpnDcUi7bY3N.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel