Getting the i2c interface from randr

[Kai-Uwe Behrmann]

Am 06.07.10 18:36, schrieb Alex Deucher:
> On Mon, Jul 5, 2010 at 3:57 AM, Richard Hughes<hughsient at gmail.com>  wrote:
>> I'm trying to do two things:
>>
>> * Control the brightness of the external panel using DDC/CI
>> * Update the pre and post LUTs on a 30bit external panel, using i2c
>>
>> I fully appreciate that different monitors have different quirks for
>> the i2c command interface. Some of these can be auto-detected and
>> worked around, some of these need quirks as they are horribly broken
>> (and I'm planning to pretty much ignore this hardware for now).
>>
>> I wanted to avoid putting yet more i2c code in X or in drm, as it's
>> quite a bit of privileged code doing fairly scary stuff with the
>> hardware, I just want to write a tiny shim library to be able to send
>> a few limited commands to the ic2 interface for the given output.
>>
>> And herein lies my problem. We don't know which i2c ports correspond
>> to which X RandR output. I assume the kernel knows, but that
>> information isn't shared with X. From the documentation I've been able
>> to scrape together, OSX has APIs were the display server just points a
>> program at an i2c interface name, and the userspace does the i2c
>> command stream as and when required.
>>
>> Of course, if you guys think this better belongs in the kernel with
>> the other i2c bits, that would probably also be sane (but quite a bit
>> of work to deal with the quirks). Comments?
>>
>
> I'm not too familiar with DDC/CI, but as far as I understand it, a few
> quirks aside, it's basically just parsing a caps list and exposing a
> list of caps and value ranges.  Would it make sense to add some common
> ddc/ci helper functions to the drm and then have the kms drm drivers
> call them to expose ddc/ci controls as connector properties (similar
> to what we already do with edid or other connector properties like
> panel scaling or tv standard)?  Then some userspace app could label
> the properties, etc. based on the edid if they vary from manufacturer
> to manufacturer.

How would a per otput property be known to be sent over DDC/CI?
EDID is a constant binary data blob.
In my understanding DDC/CI is about interactive communication. So 
exposing a system specific interface, or just its name, belonging to a 
output would reduce the client code necessary to correlate a given 
output device to a i2c device.

Property(XA_STRING) "I2C": "i2c_device_name"


kind regards
Kai-Uwe Behrmann
-- 
www.oyranos.org www.behrmann.name