Display Data Channel Command Interface (DDC/CI) ioctls [PSARC/2007/695 FastTrack timeout 01/02/2008]

[Garrett D'Amore]

Eric Sultan wrote:
> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
> This information is Copyright 2007 Sun Microsystems
> 1. Introduction
>     1.1. Project/Component Working Name:
> 	 Display Data Channel Command Interface (DDC/CI) ioctls
>     1.2. Name of Document Author/Supplier:
> 	 Author:  Eric Sultan
>     1.3  Date of This Document:
> 	14 December, 2007
> 4. Technical Description
>
> I'm sponsoring this fasttrack proposal for myself, the timer to 
> expire Jan 2, 2008.
>
> The requested binding is patch.
>
> This case proposes to add three ioctls and a supporting struct to the
> visual_io.h file.  These ioctls provide access to the VESA DDC/CI
> features supported by some display devices.
>
> Acronyms:
>   VESA    Video Electronics Standards Association
>   DDC/CI  Display Data Channel Command Interface
>   EDID    Extended Display Identification Data
>   MCCS    Monitor Control Command Set
>   i2c	  Inter-Integrated Circuit (pronounced I-squared-C)
>
> Currently, the DDC is used in Sun SPARC graphics devices only to fetch
> EDID blocks from display devices attached to graphics cards.  EDID is
> made available via a standard i2c device address in virtually all modern
> display devices.
>
> Some devices also implement a DDC/CI i2c device, and use this to
> read/write MCCS commands.  These commands offer software control of the
> display device, for example by allowing one to set the luminance or the
> gamma adjustment.
>
> Each instance of a display device may require unique settings.  An app
> concerned with calibrating and setting up a device might maintain a
> database of devices, using EDID to obtain model and serial number, and
> DDC/CI to adjust the device.
>
> This proposal adds three ioctls and the supporting struct to visual_io.h.
>
> The proposed definitions are:
>
>     #define VIS_READ_DDCCI  (('V' << 8) | 20)
>     #define VIS_WRITE_DDCCI (('V' << 8) | 21)
>     #define VIS_INIT_DDCCI  (('V' << 8) | 22)
>
>     struct vis_ddcci {
>             uint_t  port;
>             int     length;
>             caddr_t buffer;
>     };
>
>     #if defined(_SYSCALL32)
>     struct vis_ddcci32 {
>             uint_t          port;
>             int             length;
>             caddr32_t       buffer;
>     };
>     #endif /* _SYSCALL32 */
>
> Port identifies the video port on the graphics card.  Most modern graphics
> cards can drive two display devices, and this provides the selection.
>
> Length is the length of the buffer.
>
> Buffer is a pointer to a message buffer allocated by the app.  The message
> format is specified by the DDC/CI and the MCCS standards.  The message
> length is part of the message header.
>
> This proposal does not include the implementation of those ioctls in
> the device driver code.  Subsequent projects will provide
> driver-specific implementations of these interfaces.
>
> 6. Resources and Schedule
>     6.4. Steering Committee requested information
>    	6.4.1. Consolidation C-team Name:
> 		unknown
>     6.5. ARC review type: FastTrack
>     6.6. ARC Exposure: open
>
>   

How will a client know which port is which?  Are these exclusively for 
control interfaces, or is here an intent to be able to use these ioctls 
to access EDID data?

    -- Garrett