On Wed, Jul 7, 2010 at 4:43 AM, Richard Hughes <[email protected]> wrote: > On 7 July 2010 08:06, Alex Deucher <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
