Support DDC/CI and similar to automatically adjust display

Logged In: YES
user_id=1052244
Originator: NO

I am all in favor of this. Using DDC/IC for a generalized solution would be preferable but is a huge huddle at this time. On Windows platforms the only version with a native DDC/CI API is Vista and on all other Windows versions you would need to either write the interface from scratch or use one of the proprietary libraries (read $$). My understanding is that OS/X is more like the current situation with Linux and X or perhaps slightly better. Which is not in a real usable state.

There is a DDC/CI library and app for Linux/X available on sourceforge named ddccontrol (I think). But I have never been able to test it since none of my displays support DDC/CI. I also understand that there is work going on with X.Org to add a DDC/CI API to X Windows. But I have no idea when that will be in a functional state.

I think I like your idea of implementing the Eizo control interface. In particular if they are willing to supply specifications for the interface since I think we could provide them with some good PR if they were willing to do this and it would provide us with some experience doing this sort of thing that would be valuable when DDC/CI APIs are more widely available.

Logged In: NO

I've actually had a play at the Eizo interface. I can now query the monitor and enumerate it's settings. I can send it a message to adjust things like brightness, too ... but nothing happens. Yet. Argh.

I'm presently bashing together a hacky win32 app to verify that I'm sending the right messages, in which case it's probably a bug in the (rather iffy) Linux hiddev code.

Anyway, a nice discovery in all this was that the Eizo implements the USB HID Monitor standard, including a mapping of VESA controls to USB and a bunch of custom stuff too. I don't have documentation from Eizo yet, but should be able to control the RGB gains, brightness, etc even without documentation on the custom attributes - and I expect to be able to figure many of them out too since I've been using a USB protocol analyser with some success.

I expect much of this, if I can get it to work with the Eizo, will work on many other USB-enabled monitors too. I really want to see an "auto adjust" button in the accurate monitor profiler.

Unfortunately I'm rather new to USB development so I'm not sure how this will progress. Especially since I'm doing it when I'm tired of studying for exams.

Logged In: YES
user_id=639504
Originator: YES

I've written a simple command-line windows program to change monitor settings over USB and have it working well for basics like RGB gains and brightness. It should hopefully also control other USB enabled monitors that follow the USB HID Monitor spec. The code isn't ready to put up yet but once it's a little cleaner I'll pop it up here for reference.

I now know that the Eizo panel control protocol:
- Is based on USB HID
http://www.usb.org/developers/hidpage/
- Extends the USB HID Monitor protocol
http://www.usb.org/developers/devclass_docs/usbmon10.pdf
- Implements a subset of the USB HID Monitor VESA attributes
- Provides a bunch of extra non-standard control options

As for making things work on Linux ... I'm pretty sure there's a kernel bug in the way Linux handles the sending of HID Feature reports (I'm not the first to have hit problems with it) and I intend to look into it.

It sounds like Mac OS X is also reasonably sane with USB HID from userspace, so with luck it'll be possible to create a simplified (and somewhat limited) cross-platform HID interface that maps to platform-specific APIs. lprof could then use this, with the USB Monitor HID spec, to automatically adjust monitor brightness and RGB gains for profile creation.

As a side note, I've also been wondering about using argyll's colour meter code to take ambient light readings and automatically adjust the monitor luminosity to ambient light. That'd be fun and, given that an EyeOne LT is pretty cheap, not too expensive to use.

Logged In: YES
user_id=1052244
Originator: NO

Sounds like you are making progress.

The Argyll meter code uses libusb and on Windows it builds and statically links the libusb windows interface library (libusb-win32 also on sourceforge) that maps libusb calls to windows usb APIs. Of course, on Linux/Unix/BSD and OX/X machines it uses libusb natively.

The details of how we will be doing the libusb stuff on Windows still needs to be worked out. We could take the Argyll approach and build and statically link the libusb windows interface code as part of the LProf build or we could use a pre-built DLL. I think that the GSoC student is currently using a pre-built DLL.

Because LProf already requires libusb-win32 to work on Windows I think it makes sense to write all usb related stuff to the libusb API even if it is not meter related like this USB HID code.

There are now two functionality areas where LProf deals with significant platform differences. Both are hardware interface related. First is the meter interface. The second is the video card gamma setting code. The meter code uses an off the self compatibility library to handle this. In the case of the video card gamma code no such library existed and I ended up writing this. In the case of using the USB HID Monitor protocol I think the approach used for the meter code is the right one. On the other hand no such library exists for using DDC/CI directly and in fact the only platform with a native DDC/CI API is Vista and my guess is that generalizing this to use DDC/CI will require the same approach as the video card gamma code but will be significantly more complex.

It should also be possible to use any meter that will do ambient light readings to adjust monitor luminosity on the fly. This is what the Huey does. The main issue I see with this is that unlike the Huey most of these meters would be somewhat difficult to position correctly for this. That is, unlike the Huey, they don't have a stand designed to hold the meter for continuous ambient light measurements. But that is not really a software issue.

Logged In: YES
user_id=639504
Originator: YES

I don't think libusb is the right approach for monitor control, because using libusb will require that the device be detached from the OS's HID driver. That's OK on Linux where there won't be anything else using the monitor, but Windows and Mac users may well have their own vendor-supplied software talking to the device, and ideally lprof should coexist with that. If libusb-win32 can coexist with the OS's HID drivers and a similar mechanism exists for the Mac I guess that'd be OK, though I doubt it's possible.

Using the OS's HID APIs permits that coexistence, and for lprof's use it wouldn't be too hard to provide a couple of abstract classes that have different implementations on each platform - or at least a macX one, a windows one, and a generic libusb/libhid one. The required code isn't all that complex, thankfully. This would also permit the same interface to be used for DDC/CI monitors (if ever supported) as for usb ones.

Logged In: YES
user_id=1052244
Originator: NO

Some Eizo displays appear to have the ability to set the displays internal gamma table via the USB connection. This appears to only be the case with the high end "Graphics Monitors". The software provided with the monitor includes an app that calibrates the monitor, including setting the internal look up tables, using the USB connection. This app will also generate an ICC profile for the display. The software is Mac and Windows only.

If you have access to one of these higher end displays it should be possible to figure out the protocol used for setting the gamma table. At that point it would be possible to extend LProf to calibrate the look up table of these displays instead of or in addition to using the video card gamma table.

Logged In: YES
user_id=639504
Originator: YES

The S2410W also appears to support an internal RGB gamma table, at least according to the USB HID metatadata it shows and the Eizo USB SDK I've been given by Eizo. That doesn't prove it works or is active, of course, but I'd be surprised if it wasn't. Most likely the software for the CG series just ignores that feature on the S2410W. The big distinction with the CG series is the exceptionally high quality panels and the internal self-monitoring/calibration features.

I think I should be able to set the gamma table pretty easily if I have some data to put in there. It can be stored to RAM only for testing, then committed to NVRAM only once it's confirmed to be OK, so some experimentation should be acceptable.

The main issue I have right now is just time, or more specifically the lack of it.

Logged In: YES
user_id=1052244
Originator: NO

The current monitor calibration code calculates a new gamma ramp table that contains a corrected value for each level of a table of arbitrary size. The size is queried from the video card gamma table support code (but in this case it could be queried from the monitor) and in most cases this is 256 entries. For Windows it is always 256 but for X11 and OS/X system calls are used to get the actual physical table size from the video card driver. These values are normalized between 0.0 and 1.0 where for a linear (uncorrected) ramp the values would be

for (ramp_position = 0; ramp_position < ramp_size; ramp_position++)
gamma_ramp_value[ramp_position] = ramp_position/(ramp_size - 1);

Where ramp_position is in the range of 0 (black) to ramp_size - 1 (white). In other words calculating the new gamma table should not be difficult assuming you have some way to get the current values. All of the measurement code and at least a basic set of corrected ramp calculations for this are in place. So hooking this up to handle this in the monitors tables should not be too difficult (but it will not be trivial).

The current code has it's resolution limited to what is effectively 16 bits per channel. I would like to remove this limitation at some point since it probably introduces a small amount of quantization error. But it means writing some floating point gamma table code to use in place of the calls that are currently being made to the LCMS gamma table libraries which use 16 bit values. So it is likely not trivial but I will open a feature request and have a look at it. Windows and X11 currently are limited to 16 bit unsigned short values for the video card gamma tables. OS/X uses doubles between 0.0 and 1.0. So for OS/X the resolution limits for this are determined by the video hardware and it's driver.

I am not surprised that the vendors software just ignores the feature in their less expensive monitors. This is common tactic for hardware vendors. For example, Gretag-Macbeth/X-Rite does this with the EyeOne Display series meters. The only difference between an i1 Disp 2 and an i1 Disp LT is the unlock code and the software basically tries the Disp 2 unlock code and then the Disp LT unlock code if the first one did not work. And then uses a subset of the devices features if the Disp LT unlock code worked. OK there several other differences - how much it costs and what is printed on the label. At least in the Eizo case the higher end devices actually have some differences in the hardware.

Logged In: YES
user_id=1052244
Originator: NO

Today on the X.Org email list someone posted a link to a app named acddtl. This app is designed to allow controlling of the Apple Cinema displays brightness through the USB HID interface. It says it works on Linux. So it might provide some clues about how to code this stuff on a linux box. It uses libusb.

http://www.technocage.com/~caskey/acdctl/

Logged In: YES
user_id=639504
Originator: YES

I had a quick look at this while looking for more info on this topic a while ago.

IIRC it hard-codes the HID Report codes for the ADC, rather than using Usage codes to query the display to find out the correct report code to use. Maybe libhid will provide a good enough HID parser to eliminate that limitation; I'll have to take a look. In any case, as-is it's not much different to what I had working before I decided to go the hiddev route on Linux to get a proper HID parser.

The info on the gamma table calculations will be quite useful if I ever get to that point. Basic automatic display tuning is more useful. Even that's not as such important - this is definitely taking a lower priority than my PoDoFo work, moving house, or my main development project at work (argh).