search

rockowitz / ddcutil

Control monitor settings using DDC/CI and USB
http://www.ddcutil.com
GNU General Public License v2.0
979 stars 41 forks source link

DDC/CI consultancy needed #172

Closed GeorgPI closed 3 years ago

GeorgPI commented 3 years ago

Dear Mr. Rockowitz, dear All,

I am a naive novice to the concept of DDC/CI. Right now, I would like to build a monitor that supports Get/Set Brightness on Linux and Windows. I understand, for this, I will need to have the right capability string in the DDC/CI memory string. Unfortunately, I do not understand enough about the details and wondering, if someone that is specialized in this issues might be able to provide some consultancy on this.

Best regards Georg

rockowitz commented 3 years ago

If you're building a physical monitor, you probably want a chip that implements I2C. The chip manufacturer should have software for programming the chip's firmware.

Monitor Control Command Set feature xCB reports the display controller manufacturer. Its documentation, as reported by ddcutil, lists the following companies: 

VCP code C8: Display controller type  
   Mfg id of controller and 2 byte manufacturer-specific controller type  
   Simple NC values:  
      0x01: Conexant  
      0x02: Genesis  
      0x03: Macronix
      0x04: IDT
      0x05: Mstar
      0x06: Myson
      0x07: Phillips
      0x08: PixelWorks
      0x09: RealTek
      0x0a: Sage
      0x0b: Silicon Image
      0x0c: SmartASIC
      0x0d: STMicroelectronics
      0x0e: Topro
      0x0f: Trumpion
      0x10: Welltrend
      0x11: Samsung
      0x12: Novatek
      0x13: STK
      0x14: Silicon Optics
      0x15: Texas Instruments
      0x16: Analogix
      0x17: Quantum Data
      0x18: NXP Semiconductors
      0x19: Chrontel
      0x1a: Parade Technologies
      0x1b: THine Electronics
      0x1c: Trident
      0x1d: Micros
      0xff: Not defined - a manufacturer designed controller

I did find this SourceForge project that may be of interest to you.

If this monitor is for your personal use, you can probably get away with a simple implementation that works well enough for you. To be fully compliant with the DDC/CI and MCCS specifications requires a lot of attention to detail.

Good luck! Do keep me apprised of your progress.

GeorgPI commented 3 years ago

Dear Mr. Rockowitz,

thank you very much for your kind responds. As you correctly assume, I am building a physical Monitor. I have implemented HDMI and DisplayPort Displays with (LTM based IC).

The main issue now is, I need to be able to control the backlight brightness. This should be done using intrinsic controls from Microsoft Windows 10 i.e. Get/SetBrightness (or Contrast) That means, I would like to be able to control the monitor backlight without installing any drivers on the host computer.

Now, to my understanding, DDC/CI should provide this capabilities.

But as you mentioned, this is a tedious process and needs some experience with the topics.

My main question is, based on your experience, I am on the right track to try to control the Backlight via the DDC/CI channel, in order to do this without installing software on the host?

If so, then the next goal would be to implement a demonstrator that does this as you mentioned for personal use. If that work, I will have to do a more elaborate implementation that takes care of all the compatibility issues.

What is your suggestion to approach this, Should I insert a controller into the I2C path to handle this? Or would you suggest any other method?

Best regards Georg

rockowitz commented 3 years ago

On 1/20/21 6:28 AM, DLogic wrote:

Dear Mr. Rockowitz,

thank you very much for your kind responds. As you correctly assume, I am building a physical Monitor. I have implemented HDMI and DisplayPort Displays with (LTM based IC).

The main issue now is, I need to be able to control the backlight brightness. This should be done using intrinsic controls from Microsoft Windows 10 i.e. Get/SetBrightness (or Contrast) That means, I would like to be able to control the monitor backlight without installing any drivers on the host computer.

I'm afraid there's no free lunch re drivers.

At there hardware level, there's an I2C communication channel between the host and the display.  For DVI and HDMI there are dedicated pins in the cable, while for DP, I2C is carried over the general purpose AUX channel. The monitor and the video card/driver manage the low level I2C communication.  The video driver provides an interface to the I2C channel (aka bus).  On the bus, there are there are various slave addresses that can be communicated with. We're particularly interested in 2: slave address x50 that provides a simple method to read the EDID from the monitor's eeprom, and x37 that uses the DDC/CI protocol.

Windows provides a user space API (https://docs.microsoft.com/en-us/windows/win32/monitor/monitor-configuration) for communicating using DDC/CI.  I'm not familiar with what the driver stack is on Windows, but what's important is that the user space API invokes kernel services that communicate with the low level video driver.

Linux provides  no such API automatically.  Some driver must be loaded to make the I2C communication visible to user space. ddccontrol tried writing its own drivers that understood how to communicate with individual video card models.  That approach did not scale.  i2c-dev is a general purpose driver that consolidates all the i2c interfaces on various devices, and provides a user space API for accessing those interfaces.   ddcutil uses that API.  The bottom line is that without explicitly loading some driver on Linux, either the generic i2c-dev driver or some more special purpose driver, there's no access to the I2C bus on the video card.

Now, to my understanding, DDC/CI should provide this capabilities.

But as you mentioned, this is a tedious process and needs some experience with the topics.

My main question is, based on your experience, I am on the right track to try to control the Backlight via the DDC/CI channel, in order to do this without installing software on the host?

To continue, I imagine you're referring to some existing Windows application that knows how to use the Windows monitor configuration API.  It may come pre-installed on Windows, it may be an application provided by the monitor maker, e.g. the Dell Display Manager.

Given the nature of Linux, there's no such application "out of the box".   At best, some distributions package an application like ddcutil that knows how to use the API.

DDC/CI is a very low level protocol.  Think of it as UDP, not TCP. ddcutil understands how to use it, and can cope with much of the variability in how monitors implement the protocol, but that is not the concern here.

If so, then the next goal would be to implement a demonstrator that does this as you mentioned for personal use. If that work, I will have to do a more elaborate implementation that takes care of all the compatibility issues.

What is your suggestion to approach this, Should I insert a controller into the I2C path to handle this? Or would you suggest any other method?

Again, my suggestion is that if possible you find a controller chip that implements DDC/CI rather than trying to roll your own.

Best regards Georg

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/172#issuecomment-763539441, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3V6MXLF4EDH5QHR76TS2245ZANCNFSM4WIPTRDA.

GeorgPI commented 3 years ago

Dear Mr Rockowitz

thank you for your excellent suggestions and thoughts on the DDC/CI. I completely agree with you, (https://docs.microsoft.com/en-us/windows/win32/monitor/monitor-configuration) the monitor configuration method provided by Windows is the right point to hook up. The user space application has to be able to use the above mentioned API.

Hence, the Monitor needs to comply with the DDC/CI standard to be able to seamlessly integrate with the Windows operating system (the same will hold for Linux).

Best regards

Georg Israel