On Wed, Jul 7, 2010 at 2:44 AM, Kai-Uwe Behrmann <[email protected]> wrote: > Am 06.07.10 18:36, schrieb Alex Deucher: >> >> On Mon, Jul 5, 2010 at 3:57 AM, Richard Hughes<[email protected]> >> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
