Getting the i2c interface from randr

[Richard Hughes]

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 :-)

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.

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

Richard.