Getting the i2c interface from randr

[Alex Deucher]

On Wed, Jul 7, 2010 at 2:44 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> 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?

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.

brightness <0 - 50>
contrast <0 - 50>
colorpreset <1-4>
language <1-5>
or
0x10 <0-50>
0xe6 <1-5>
0x14 <0-7>
etc.

> EDID is a constant binary data blob.

Yes. You need the EDID to identify the monitor manufacturer.

> 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"

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.  You'd
then have a userspace app (gnome display manager or gnome color
manager or whatever) that would maintain a database of monitors and
match the exposed control numbers to human readable names.  That app
could then get/set the control value via xrandr or sysfs.

Alex