From egs@thirdreef.sfbay.sun.com Fri Dec 14 16:50:23 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBF0oMqZ018604 for ; Fri, 14 Dec 2007 16:50:23 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBF0o27q021075 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 15 Dec 2007 00:50:21 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT200M05FNV4G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Dec 2007 16:50:19 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT200IYDFNVRG40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Dec 2007 16:50:19 -0800 (PST) Received: from thirdreef.sfbay.sun.com (thirdreef.SFBay.Sun.COM [129.146.94.117]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBF0oIrr006397; Fri, 14 Dec 2007 16:50:18 -0800 (PST) Received: from thirdreef.sfbay.sun.com (localhost [127.0.0.1]) by thirdreef.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBF0gn4i001294; Fri, 14 Dec 2007 16:42:49 -0800 (PST) Received: (from egs@localhost) by thirdreef.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id lBF0gnou001291; Fri, 14 Dec 2007 16:42:49 -0800 (PST) Date: Fri, 14 Dec 2007 16:42:49 -0800 (PST) From: Eric Sultan Subject: Display Data Channel Command Interface (DDC/CI) ioctls [PSARC/2007/695 FastTrack timeout 01/02/2008] To: PSARC-ext@sun.com Cc: joe.miseli@sun.com, ron.bielaski@sun.com Message-id: <200712150042.lBF0gnou001291@thirdreef.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2907 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 From gdamore@sun.com Fri Dec 14 17:10:53 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBF1ArLq019085 for ; Fri, 14 Dec 2007 17:10:53 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBF1AqB6028867; Fri, 14 Dec 2007 17:10:53 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT200N01GM41L00@nwk-avmta-2.sfbay.sun.com>; Fri, 14 Dec 2007 17:10:52 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT200IGRGM4RS50@nwk-avmta-2.sfbay.sun.com>; Fri, 14 Dec 2007 17:10:52 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBF1AqkZ028221; Fri, 14 Dec 2007 17:10:52 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT200901GDSC400@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Fri, 14 Dec 2007 17:10:52 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT200AGPGM39A90@fe-sfbay-09.sun.com>; Fri, 14 Dec 2007 17:10:52 -0800 (PST) Date: Fri, 14 Dec 2007 17:05:15 -0800 From: "Garrett D'Amore" Subject: Re: Display Data Channel Command Interface (DDC/CI) ioctls [PSARC/2007/695 FastTrack timeout 01/02/2008] In-reply-to: <200712150042.lBF0gnou001291@thirdreef.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Eric Sultan Cc: PSARC-ext@sun.com, Joe.Miseli@sun.com, ron.bielaski@sun.com Message-id: <4763284B.1070606@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712150042.lBF0gnou001291@thirdreef.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 3265 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 From Eric.Sultan@sun.com Fri Dec 14 17:35:55 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBF1Zs0J019422 for ; Fri, 14 Dec 2007 17:35:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBF1ZpKu003490; Sat, 15 Dec 2007 01:35:51 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT200701HRRTV00@brm-avmta-1.central.sun.com>; Fri, 14 Dec 2007 18:35:51 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT200I3KHRQNKB0@brm-avmta-1.central.sun.com>; Fri, 14 Dec 2007 18:35:50 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBF1Zoew010838; Sat, 15 Dec 2007 01:35:50 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT200101HQMAM00@mail-amer.sun.com> (original mail from Eric.Sultan@Sun.COM); Fri, 14 Dec 2007 18:35:50 -0700 (MST) Received: from [129.146.94.117] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT200J94HRPRE20@mail-amer.sun.com>; Fri, 14 Dec 2007 18:35:49 -0700 (MST) Date: Fri, 14 Dec 2007 17:35:49 -0800 From: Eric Sultan Subject: Re: Display Data Channel Command Interface (DDC/CI) ioctls [PSARC/2007/695 FastTrack timeout 01/02/2008] In-reply-to: <4763284B.1070606@sun.com> Sender: Eric.Sultan@sun.com To: "Garrett D'Amore" Cc: Eric Sultan , PSARC-ext@sun.com, Joe.Miseli@sun.com, ron.bielaski@sun.com Reply-to: Eric.Sultan@sun.com Message-id: <47632F75.3070905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712150042.lBF0gnou001291@thirdreef.sfbay.sun.com> <4763284B.1070606@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 877 Garrett D'Amore wrote: > ... > 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 The client, or his installation, connected the monitors and so knows which is which. Even so, he can fetch EDID info from the two ports and learn what's connected. By convention, the ports are labeled "1" and "2". These ioctls are exclusively for DDC/CI. The same struct would work for EDID, but one would need to use the EDID i2c address instead of the DDC/CI i2c address. The format of the payload in the buffer is different for EDID and for DDC/CI. Currently, in SPARC graphics at least, each device has its own ioctls for fetching EDID. I'd prefer to define a generalized set for EDID, but that's beyond the scope of this proposal. -- Eric From gdamore@sun.com Fri Dec 14 20:27:43 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBF4RhbN029625 for ; Fri, 14 Dec 2007 20:27:43 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBF4Rbpc012795; Sat, 15 Dec 2007 04:27:40 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT200K13PQ29800@brm-avmta-1.central.sun.com>; Fri, 14 Dec 2007 21:27:38 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT200F9MPPZA8F0@brm-avmta-1.central.sun.com>; Fri, 14 Dec 2007 21:27:35 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBF4RZwa004015; Fri, 14 Dec 2007 20:27:35 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT200201PG2D800@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Fri, 14 Dec 2007 20:27:35 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT200KN0PPYOJB0@fe-sfbay-09.sun.com>; Fri, 14 Dec 2007 20:27:35 -0800 (PST) Date: Fri, 14 Dec 2007 20:21:59 -0800 From: "Garrett D'Amore" Subject: Re: Display Data Channel Command Interface (DDC/CI) ioctls [PSARC/2007/695 FastTrack timeout 01/02/2008] In-reply-to: <47632F75.3070905@Sun.COM> Sender: Garrett.Damore@sun.com To: Eric.Sultan@sun.com Cc: Eric Sultan , PSARC-ext@sun.com, Joe.Miseli@sun.com, ron.bielaski@sun.com Message-id: <47635667.9010502@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712150042.lBF0gnou001291@thirdreef.sfbay.sun.com> <4763284B.1070606@sun.com> <47632F75.3070905@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1130 Eric Sultan wrote: > Garrett D'Amore wrote: >> ... >> 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 > The client, or his installation, connected the monitors and so knows > which is which. > Even so, he can fetch EDID info from the two ports and learn what's > connected. > > By convention, the ports are labeled "1" and "2". > > These ioctls are exclusively for DDC/CI. The same struct would work > for EDID, > but one would need to use the EDID i2c address instead of the DDC/CI > i2c address. > The format of the payload in the buffer is different for EDID and for > DDC/CI. > > Currently, in SPARC graphics at least, each device has its own ioctls > for fetching EDID. > I'd prefer to define a generalized set for EDID, but that's beyond the > scope of this proposal. Understood, thanks for the clarification. I've never used DDC/CI, and didn't realize that there was a separate i2c address, but now that I think about it it makes perfect sense. ;-) -- Garrett From Eric.Sultan@sun.com Wed Dec 19 16:15:12 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBK0FCCC006435 for ; Wed, 19 Dec 2007 16:15:12 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lBK0FAaL011742; Wed, 19 Dec 2007 16:15:12 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JTB00J0FNDAWT00@brm-avmta-1.central.sun.com>; Wed, 19 Dec 2007 17:15:11 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JTB006Z2NDANJB0@brm-avmta-1.central.sun.com>; Wed, 19 Dec 2007 17:15:10 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBK0FA8q009413; Thu, 20 Dec 2007 00:15:10 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTB00901N345U00@mail-amer.sun.com> (original mail from Eric.Sultan@Sun.COM); Wed, 19 Dec 2007 17:15:09 -0700 (MST) Received: from [129.146.94.117] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTB0027BND8NK30@mail-amer.sun.com>; Wed, 19 Dec 2007 17:15:09 -0700 (MST) Date: Wed, 19 Dec 2007 16:15:08 -0800 From: Eric Sultan Subject: Re: Display Data Channel Command Interface (DDC/CI) ioctls [PSARC/2007/695 FastTrack timeout 01/02/2008] In-reply-to: <200712150042.lBF0gnou001291@thirdreef.sfbay.sun.com> Sender: Eric.Sultan@sun.com To: Eric Sultan Cc: PSARC-ext@sun.com, Joe.Miseli@sun.com, ron.bielaski@sun.com Reply-to: Eric.Sultan@sun.com Message-id: <4769B40C.4030109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200712150042.lBF0gnou001291@thirdreef.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 100 There having been no unresolved issues, this case was approved in today's PSARC meeting. -- Eric