Directfb Xorg server/Color calibrating X11 displays.

[Mike Emmel]

First as I said I've not looked at this in detail.
But I think all this needs to be back in the driver/directfb layer.

If there is a protocol at the x level thats a different story.
Also its not clear what the entire requirments are for example lcd displays.
They have different requirements from a monitor.

are very common today. In any case I'd love to see all this
functionality avialable outside
of X11 its a shame its tied to the xserver today.

In any case I'm a looong way from worrying about gamma correction at the moment
its probably years away.

Mike



On 5/31/06, Graeme Gill <graeme2 at argyllcms.com> wrote:
> 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.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>