Getting the i2c interface from randr

[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.

Alex