Problems with monitor calibration and MergedFB/TwinView

[Graeme Gill]

Alex Deucher wrote:

> I just don't like people expecting something to get done and then if
> they don't get an immediate response, they asume the worst and then
> make some comment about how open source developers just don't care
> about problem X.  For the most part we are all volunteers.  I, and I'm
> sure plenty of other developers would like to see good color
> management, but it's a lot further down my list than stablizing
> drivers and improving basic functionality.  Anyway, this part of the
> conversation is no longer productive so lets get back to the issue at
> hand.

I don't see that there's going to be much progress in improving
things if the response to any raising of problems or suggestions
for improvements is to ignore them or reply with the
"the source code's there, do it yourself" response.

When people raise difficult feature or problem issues with
my open source software, the way I try and respond is to
engage in a conversation to identify exactly what the
problem or suggestion is, and why, so that possible
fixes or improvement avenues are fully understood.
It goes in a list. If it's easy, it might get fixed/improved
soon. If it's hard or a lot of work, then I try and explain
exactly why it is hard, people are usually pretty understanding
of the situation. I certainly have no expectation that someone
who wants to use the code, actually understands enough about
it to know where to begin in modifying it themselves.

As for the sort of thing I'm raising being way down
the list because of stabilizing drivers and improving
basic functionality, then I'm afraid I'm a little
bemused. It's not like X11 is a new system that's
just been released, and hence would be expected to
have under-developed API's, and an emphasis on
just getting something that works "out there". It's been
around a long time, and it's a little disappointing that
simple stuff like API's to handle multiple displays
properly haven't been worked out sufficiently,
especially when there are other examples around
of how to organize things (MSWindows, OS X). X11 is
in catch-up, and it would be good to see it making
progress on catching up.

API/functionality design is really orthogonal to
the process of rolling out a particular release or
version that supports some new hardware or features etc.,
so I don't think it can be put in the same priority
list as everything else. It should really be a higher
priority, so that the actual implementation effort
isn't wasted on a design with fundamental flaws or
limitations. That's what really bugs me about the
calibration/VideoLUT/RAMDAC access problem - from
my understanding, it seems like one of those things that's
almost as easy to do right, as it is to do the wrong way.

> IIRC, VidModeExtension works on X screens.  with mergedfb there is
> only 1 screen (just happens to have 2 monitors attached to it.

But there are two video channels, one to each monitor, and
it's almost certain that each channel has it's own RAMDAC,
(and even it's own video parameters I would imagine in
many cases) so there's no logical reason why the VidModeExtension
isn't presenting 2 screens. You're talking "input" (CPU/GPU access
to the frame buffer), and I'm talking "output" (video streams
to the displays). There may well be practical limitations, if
one is working through vendors binaries drivers of course.

Plain X11 running Xinerama works this way. The main X11 protocol
stream acts like there is one (virtual) screen, while
the VidModeExtension is ignorant of Xinerama, and supports the
underlying (real) screens.

> yes and they also have teams of engineers both internally and with the
> various hardware vendors working full time on those sorts of things.
> It was probably more work than it would seem.  Windows and Macos
> presumably have a well designed mult-head infrastructure.  X does not
> at the moment.

Sorry, I'm having trouble buying the "it's a really difficult
feature to implement" response. The current code must be almost
going out of it's way to make it not work, since for two video
outputs from the same frame buffer, there have to be two sets
of refresh logic, and two RAMDAC's that go with them. When you're
presenting a single X11 screen, something must be being done to
deal with the two sets of hardware setup, rather than just
keeping them separate and presenting them that way.

Now I am sympathetic to a situation in which the vendor libraries
are creating the problem, and not being responsive to fixing
it (or even entertaining feedback on it!), and that you
are just volunteer in the middle, doing the best you can
in your own time, with what they provide.

I am also quite happy to buy the "there's some rather difficult
architectural/API design that has to be settled before progress
can be made in fixing this problem properly", and perhaps it
make more sense to wait for RandR, rather than jumping through
hoops to fix it in current implementations. If it's a vendor
driver that's the problem though, they are still going to
have to fix things for RandR.

>> If you're going to provide a "virtual" screen that covers
>> all the real screens, just make sure there's a way
>> of accessing the real screens as well, rather than
>> cutting off all communication channels. Xinerama
> 
> You are not understanding mergedfb.  there is only one underlying
> screen.  It is basically a driver side hack that allocates a double
> sized chunk of framebuffer and points both crtcs into it. there are no
> underlying :0.0 and :0.1, just :0.0.  As such I don't see how you
> could make this work with the VidMode.  How do you tell it what screen
> to adjust?

I understand, but it's a rather odd piece of hardware that
uses the same refresh logic and RAMDAC to output to both
screens (how would it do it ? interleave pixel by pixel
and de-interleave afterwards to separate D/A converters ??).
Is that really the case, or is it that the vendors binary lump
doesn't expose the access to the RAMDACs ?
If you can access the CRTCs, can you access the RAMDACs associated
with them independently ?

While it's natural in this arrangement to have only one
X11 screen, one way to fix it (at least as far as supporting
RAMDAC access at a protocol level) is to emulate/implement the
XVidModeExtension such that it does have screens :0.0, :0.1 in this
situation (treating the normal X11 multi-screen/Xinerama behaviour
as a de facto standard), so that rather than returning an X error for
trying to access screen :0.1 via the XVidModeExtension, treat it
as accessing the second CRTCs RAMDAC, while screen :0.0 accesses
the first CRTCs.

> If they want support they'll have to stick with "regular" dualhead and
> xinerama for now.  Hopefully some of the new developments I mentioned
> previously will address this.

Yes, this is my conclusion at the moment. By intercepting the
X errors and ignoring them, it is possible to work in a compromised
fashion (ie. color calibrating for one display, and allowing the other
displays to use the erroneous calibration), and compensate to some
degree by color profiling both displays independently, but while
every application gets to use the calibration, applications only
selectively use profiles, and the profile is less accurate on
an uncalibrated display.

Graeme Gill.