Getting the i2c interface from randr

[Alex Deucher]

On Wed, Jul 7, 2010 at 4:43 AM, Richard Hughes <hughsient at gmail.com> wrote:
> On 7 July 2010 08:06, Alex Deucher <alexdeucher at gmail.com> wrote:
>> You'd expose a separate connector property for each ddc/ci control.
>> You could either name them for common ones, or just list them based on
>> the control number.  E.g.
>
> It's not really just a set of properties, it's a proper command
> interface. See http://en.wikipedia.org/wiki/Display_Data_Channel#DDC.2FCI
> -- I really don't want to feel the bitter wrath of Matthew Garrett
> when I add a 30ms poll in the kernel just to keep some of the
> properties up to date and the i2c link up :-)
>

Ah, ok.  I didn't realize the timing details.

> It's also horribly vendor specific. For instance, I want to update the
> PMB data block in a DreamColor HP monitor. To do this I have to make
> raw calls like http://www.boichat.ch/nicolas/ddcci/specs.html -- which
> the possible kernel interface would have to support. There's no way I
> could break this vendor specific block of memory into meaningful
> properties and ever hope to have any sort of kernel<--->device
> coherence.
>

BTW, I realize there are some monitor specific controls, but I think
most of them are standardized.  Take a look at the DDC/CI and MCCS
VESA specs.  If you are an X.org member, you have free access to the
VESA specs:
http://wiki.x.org/wiki/Membership
Having looked at the MCCS spec and the ddccontrol package and monitor
database, most of the reverse engineered controls look to be standard
MCCS controls.

>>> Property(XA_STRING) "I2C": "i2c_device_name"
>
> Right, this makes sense.
>
>> Rather than having a userspace app due the i2c transaction, you'd just
>> expose the controls listed in the ddc/ci interface provided by the
>> monitor and the kernel would do the actual i2c transaction.
>
> That would mean putting a lot of different, often horrible, horrible
> quirks in the kernel.
>
>> That app could then get/set the control value via xrandr or sysfs.
>
> I'm not sure that's complete enough for the second use-case. For
> brightness it kinda makes sense, and then we can even wire in
> backlight support to external panels so that xrandr capable programs
> magically gain support. But for the more advanced usages, we really
> need the raw ic2 device.

If you just need the i2c device that's easy.

Alex