Directfb Xorg server/Color calibrating X11 displays.

Graeme Gill graeme2 at argyllcms.com
Wed May 31 00:09:17 PDT 2006


Mike Emmel wrote:

> Anyway I'm trying to split the api avialable in X into two groups
> 
> A.) Api that are almost always local i.e co-server and seldom used by
> applications.
> B.) Desktop/Hardware managment
> C.) The standard application apis used by programs.
> 
> Supporting the C group is the initial goal understanding the impact of 
> removing.
> Directfb based solutions will be used for A and be initially via 
> gtk/directfb.

 From the perspective of supporting color calibration and profiling of
X11 displays, the main considerations are:

1) Accessing the hardware video lookup tables. The XF86VidMode
    "GammaRamp" functions are the only semi-standardized X11
    way of doing this that I'm aware of.

2) Locating and accessing the physical displays. There seems
    no way of quickly locating X11 Displays, or getting a description
    of them. Simply trying to open them takes too long, so this gets
    thrown back on the user to somehow "know" what to specify. (not very friendly)

    Selecting screens is somewhat easier, but getting some sort
    of identifiable description of them depends on the XF86VidMode
    extension once again. Having to know about, and deal with random
    extensions (Xinerama) doesn't help (ie. it might be good if there
    was a common distinction between selecting logical and physical screens,
    so that future Xinerama like extensions don't have to work around
    the issue by providing extension specific workaround functions, which
    then every application that wants to access the physical screen has
    to know about.)

3) Accessing the displays DDC/CI channel, to adjust the screen
    controls (brightness, contrast, color temperature etc.) automatically.
    This seems to be a lost cause at the moment under X11. While the DDC
    channel is often used in starting the X11 server to read the EDID,
    it is not made available to applications that need/want to adjust
    display settings. There is a project that goes in this direction
    somewhat (DDIcontrol), but it is not properly integrated
    into X11 - the application drawing the test colors should be
    able to access the same display.screen's DDC/CI channel, not
    rely on the user to make the association, and not have to incorporate
    all sorts of device dependent access code (that's what an X11 display
    driver is meant to be shielding the application from!)
    This could be a low level function that allows the application to
    read and write DDC messages, or it could be a higher level
    function that allows "brightness", "contrast" etc. to be
    read and set (encapsulating any display differences).

4) Turning off things that interfere with calibrating/profiling the
    display, such as screensavers and power savers. While X11 does
    have a standard way of turning the screensaver off, it doesn't
    actually work with the most popular screensaver "xscreensaver",
    and dealing with power saving relies on another extension.
    What's actually needed is a standard way that all such utilities
    hook into, that the application can indicate a "there is activity"
    heartbeat, analogous to:

    SetThreadExecutionState():
    <http://msdn.microsoft.com/library/en-us/power/base/setthreadexecutionstate.asp?frame=true>
    UpdateSystemActivity():
    <http://tuvix.apple.com/documentation/Carbon/Reference/Power_Manager/Reference/reference.html>

    Such a facility would greatly be appreciated by slide show and video playback
    applications as well.

5) Providing a mechanism to access a screens ICC profile. There is a semi-standardized
    mechanism for accessing the correct ICC profile using the _ICC_Profile atom property
    of the root window <http://www.burtonini.com/computing/x-icc-profiles-spec-0.1.html>,
    although the lack of a distinction between logical an physical screens has
    made this a little awkward
    - see <http://lists.freedesktop.org/archives/openicc/2006q2/000727.html>

1) and 3) probably don't need or want to be remotely accessible functions, but a
standardized, possibly cleaner way of doing all this stuff is desirable.

Graeme Gill.



More information about the xorg mailing list