ddcutil Unable to control BenQ GL2250HM monitor

Hi,

I'm running into an issue, where I can't control this BenQ monitor with ddcutil.

The monitor has 2 connected inputs DVI and HDMI. DVI is connected to the motherboard's integrated graphics card and HDMI to gtx 1060, which I'm using exclusively in a window VM with PCI pass-through. The main host is running ubuntu 16.04. Hence, I'm looking for software switch that I could switch inputs on my monitor.

DDC/CI is mentioned in monitor's manual as supported and is enabled in on-screen settings.

What I've done so far to debug this - picked up 0.9.8 release and compiled it (as it wasn't available in systems packages). The basic when I run detect command:

$ ./build/bin/ddcutil detect
Invalid display
   I2C bus:             /dev/i2c-2
   EDID synopsis:
      Mfg id:           BNQ
      Model:            BenQ GL2250H
      Serial number:    ABE02389019
      Manufacture year: 2014
      EDID version:     1.3
   DDC communication failed

Here are more verbose outputs that I could think of captured: ddcutil-interrogate.txt ddcutil-env-verbose.txt ddcutil-getvcp-0x60.txt ddcutil-getvcp-scan.txt

I've seen somewhere in these issues recommended softMCCS. I've tried on windows VM and it was able to detect the monitor correctly and change most settings as well as the input. To rule out DVI, I've also booted the machine to windows natively and tried this again and it was able to detect both inputs connected the same way to the PC and control each of them. In my mind, this likely rules out any possible hardware issues.

So, I'm a little bit lost now, not sure where to look next. I couldn't find any good documentation on DDC protocol for better understanding what is happening.

I'd appreciate any help :)

Thanks in advance, Arnoldas

Mar 24 '20 12:03 arnoldas-jasonas

First, let me say I appreciate the completeness of your problem report. I don't know if we'll be able to solve it, but we won't go through several rounds of repeated requests for the output of the diagnostic programs and various other basic tests. Since your report was quite complete I'll try to make mine so as well.

This reply is TMI. However, it was useful to write this stuff down for incorporation in the ddcutil documentation. Here's the executive summary:

What happens if you use a different monitor? What happens if you use the Benq monitor on a Linux system with a driver other than i915?
Try option --sleep-multiplier, e.g. "ddcutil getvcp 10 --sleep-multiplier 4.0"
Is there anything interesting in the softMCCS DDC/CI communication log?
The Windows video drivers are just better than the Linux drivers at handling monitors with marginal I2C implementations.

Regards, Sanford

In no particular order, some observations and comments.

The problem is in DDC communication. Feature x60 may be problematic, but that is not relevant here.
softMCCS is the best tool I know for testing monitor DDC functionality. As you probably know, enTech makes DDC chips for monitors. softMCCS is a tool for monitor customers to test their implementations. It's safe to say the enTech understands DDC as well as anyone around. I don't know if softMCCS uses the core Windows DDC API, or a lower level API. You night look for anything interesting in its DDC/CI communication log. (Low probability).
ddcutil uses the dev-i2c userspace driver. The kernel side of the driver in turn uses the video driver.
In the getvcp trace, the call into i2c-dev fails for feature x00, with Linux errno ENXIO. If a monitor supports DDC, ddcutil expects to see a properly formed DDC response indicating that it doesn't support that feature. So ddcutil decides that DDC is unsupported. (It's a bit more complicated than that. There are monitors that trigger ENXIO in response to a query for any unsupported feature. But for our purposes here that doesn't matter.
In the environment command, ddcutil doesn't make any preliminary check of whether a monitor supports DDC, it just tries to get the value of feature x10 (brightness) which any monitor implementing DDC will support. Here ddcutil tries to read the value by directly writing to and reading from the /dev/i2c bus without using the usual layering. The the output is interesting, the first response is all 0, the second returns ENXIO. Again, an all 0 response is ambiguous. I have occasionally seen monitors that use it to indicate an unsupported feature. Usually it indicates that the monitor hasn't had time to compose a proper response, so it is a retryable error. That the second request returns ENXIO, a different error condition, indicates that we indeed have a DDC communication problem.
There are several possible causes of DDC communication failure.

First, it may just be the particular monitor/video card/driver combination. If you have another monitor around, what happens if you use that monitor instead? What happens if you use the Benq on a different Linux system, preferably with a different video driver?

Second, there are monitors that can't keep up with the 100Mhz bus speed. Or sometimes they do and sometimes they don't. A few years ago there was an experimental change to the i915 driver to lower the I2C bus speed when communicating with slave address x37 (DDC). It never made it into a released version. I don't have a solution for this.

Third, the monitor may just be slow and needs more time than allotted by the DDC/CI specification to formulate a reply. You can try using the --sleep-multiplier option to tell ddcutil to wait longer between writing a request and attempting to read a reply, e.g. $ddcutil getvcp 10 --speed-multiplier 2.0

Why does the monitor work on Windows and not Linux? First, the Windows video drivers may just be better accommodating marginal monitors, e.g. by slowing the bus speed. This of course is just conjecture on my part. Second, I doubt manufacturers test their monitors on Linux.
The correct DDC documentation is indeed hard to identify locate by searching. The DDC protocol evolved, being part of Access Bus at one point, and shedding various pieces, e.g. EDID, into separate protocols. See the Wikipedia DDC page (https://en.wikipedia.org/wiki/Display_Data_Channel) to see how it morphed. You're looking for are the following document:

VESA Display Data Channel Command Interface Standard, Version 1.1, October 29, 2004 (https://app.box.com/s/vcocw3z73ta09txiskj7cnk6289j356b/file/93518804682) The current most definitive document.

VESA Display Data Channel Command Interface Standard, Version 1, August 14, 1998 (http://read.pudn.com/downloads84/ebook/322616/ddcciv1.pdf). Its description of the protocol helps clarify version 1.1.

VESA Access.bus Specification Version 3.0 (https://app.box.com/s/vcocw3z73ta09txiskj7cnk6289j356b/file/93518584526) for its low level description of the I2C protocol.

The most current Monitor Control Command Set spec is VESA Monitor Control Command Set Standard Version 2.2a, 13 January 2011 (https://app.box.com/s/vcocw3z73ta09txiskj7cnk6289j356b/file/93517210750/

There is an earlier MCCS standard (http://read.pudn.com/downloads515/doc/2139715/mccsV3.pdf), 3.0, that was too much of a departure from version 2.1, and did not gain traction. However, the documentation can be informative.

More generally, see the VESA standards page: https://vesa.org/vesa-standards/

A very nice description of I2C is found in a paper I found recently, HDCP and EDID Demystified from Luxi Electronics (https://luxielectronics.com/attachments/File/HDCP_and_EDID_Demystified.pdf).

Finally, there's the i2c-dev documentation in Linux itself. The documentation is dated - the next release of i2c-dev will have a major update.

For more extensive list, see http://www.ddcutil.com/bibliography/.

On 3/24/20 8:28 AM, Arnoldas wrote:

Hi,

I'm running into an issue, where I can't control this BenQ monitor with /ddcutil/.

The monitor has 2 connected inputs DVI and HDMI. DVI is connected to the motherboard's integrated graphics card and HDMI to gtx 1060, which I'm using exclusively in a window VM with PCI pass-through. The main host is running ubuntu 16.04. Hence, I'm looking for software switch that I could switch inputs on my monitor.

DDC/CI is mentioned in monitor's manual as supported and is enabled in on-screen settings.

What I've done so far to debug this - picked up 0.9.8 release and compiled it (as it wasn't available in systems packages). The basic when I run detect command:

|$ ./build/bin/ddcutil detect Invalid display I2C bus: /dev/i2c-2 EDID synopsis: Mfg id: BNQ Model: BenQ GL2250H Serial number: ABE02389019 Manufacture year: 2014 EDID version: 1.3 DDC communication failed |

Here are more verbose outputs that I could think of captured: ddcutil-interrogate.txt https://github.com/rockowitz/ddcutil/files/4375134/ddcutil-interrogate.txt ddcutil-env-verbose.txt https://github.com/rockowitz/ddcutil/files/4375131/ddcutil-env-verbose.txt ddcutil-getvcp-0x60.txt https://github.com/rockowitz/ddcutil/files/4375132/ddcutil-getvcp-0x60.txt ddcutil-getvcp-scan.txt https://github.com/rockowitz/ddcutil/files/4375133/ddcutil-getvcp-scan.txt

I've seen somewhere in these issues recommended softMCCS. I've tried on windows VM and it was able to detect the monitor correctly and change most settings as well as the input. To rule out DVI, I've also booted the machine to windows natively and tried this again and it was able to detect both inputs connected the same way to the PC and control each of them. In my mind, this likely rules out any possible hardware issues.

So, I'm a little bit lost now, not sure where to look next. I couldn't find any good documentation on DDC protocol for better understanding what is happening.

I'd appreciate any help :)

Thanks in advance, Arnoldas

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/115, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3RFMHPXNZCNTVRYTA3RJCROLANCNFSM4LSTOBGQ.

Mar 24 '20 20:03 rockowitz

Thanks a lot for detailed response. (Another long wall of text/logs incoming ...)

I managed to skim through few of the documents, but I'm still struggling with few concepts. Specifically, it's not quite clear to me how I2C bus is used to create DDC messages. I'll try to do more reading to understand this better. By the way, one of your links (https://app.box.com/s/vcocw3z73ta09txiskj7cnk6289j356b/file/93517210750/) seems to have died.

I don't have another monitor at the moment to test with i915 driver. However, I did try both outputs booted with live Ubuntu 18.04. I've also tried controlling the monitor via Raspberry Pi 3.

I've tried quite a few combinations and captured logs of almost everything. So, I hope you'll excuse me for far too many log files :) I thought it might be easier to ignore what is not relevant rather then trying to capture something again ...

What happens if you use the Benq monitor on a Linux system with a driver other than i915?

First interesting observation - It seems to work all fine when controlling the monitor via dGPU using nouveau driver.

Second observation, it doesn't look like either DVI or HDMI inputs on the monitor are flawed in any way. I've tried swapping cables out (both are HDMI at the PC's end). Second time the HDMI input is connected to iGPU and it stops working, while DVI input connected to dGPU is functioning fine. Note, the OS was set to mirror displays and I was able to control it when either HDMI or DVI input was active.

Third, when running the same failing command multiple times, it seems to fail in different ways. Some examples with different run numbers below.

I've tried repeating the commands one after another with couple of seconds in between. In my mind, it would suggests that some kind of registers are not being reset correctly after a failure. I suppose the i915 drivers would be at fault here.

Interestingly enough, I did try the sleep multiplier at couple suggested values as well as at much larger ones, but it seems to fail similarly although obviously it takes noticeably longer.

So, it seems like both DVI and HDMI inputs on monitor side are functioning and it's likely iGPU drivers at fault. Do you have any more ideas of what I could try or look at? I was thinking whether it's possible to just do some kind of bit-banging on I2C directly without relying on the kernel side driver at all.

Test 2, where iGPU is attached to HDMI and dGPU to DVI and then DVI input is fully functional: ddcutil-interrogate.txt ddcutil-env-verbose.txt Functional DVI examples: ddcutil-i2c-6-dvi-getvcp-0x60.txt ddcutil-i2c-6-dvi-setvcp-0x60-0x03.txt ddcutil-i2c-6-dvi-setvcp-0x60-0x11.txt ddcutil-i2c-6-dvi-getvcp-0x10_run1.txt ddcutil-i2c-6-dvi-getvcp-0x10_run2.txt Tries for 0x10 and 0x60 registers, with sleep multiplier example and also repeated, to show different failures: ddcutil-i2c-18-hdmi-getvcp-0x10_run1.txt ddcutil-i2c-18-hdmi-getvcp-0x10_run2.txt ddcutil-i2c-18-hdmi-getvcp-0x60_run1.txt ddcutil-i2c-18-hdmi-getvcp-0x60_run2.txt ddcutil-i2c-18-hdmi-setvcp-0x60-0x11_sleep-8.0_run1.txt ddcutil-i2c-18-hdmi-setvcp-0x60-0x11_sleep-8.0_run2.txt

For completeness to isolate any combination of problems between PC and monitor, I've also tried on Raspberry Pi.

Funny enough, I could not get HDMI input to work, while it worked fine when connected (with the same cable) to DVI. I suspect it is a separate issue. Logs are here as well, but error codes seem different to me which probably points to a different Pi specific issue.

And lastly,

Is there anything interesting in the softMCCS DDC/CI communication log?

Not really sure how to interpret the log. Seems like all messages are going through, but I am not sure what data is being printed in there. In this log I've tried adjusting the brightness and switched the input. softMCCS_log.txt

I do appreciate your time and I hope it's not too much information to scan through. If I can present it somehow better, please do let me know. Likewise, if there is something specific I could dig in more better understand the problem - I'm happy to go away do my reading first.

Thanks, Arnoldas

Mar 26 '20 22:03 arnoldas-jasonas

First let me try to address your general questions about I2C.

My apologies on the invalid link - it must have been generated for me specifically. All the files on box.com are once from the VESA web site. Go to https://vesa.org. Navigate Standards & Specs ->Free Standards. There's a big block of text that ends with "They can all be downloaded here..." Click on the link, which will take you to a registration page. Once you've filled out the form, you'll have access the the downloads. The one you're primarily interested in is DDCCI.

I2C is a low level specification of a 2 wire protocol for sending and receiving sequences of bytes. For the gory details, see https://i2c.info, https://i2c.info/i2c-bus-specification, https://en.wikipedia.org/wiki/i2c. I particularly like the "HDCP and EDID Demystified" paper (https://luxielectronics.com/attachments/File/HDCP_and_EDID_Demystified.pdf) that I mentioned earlier. DDC is a particular use of that specification. It describes how sequences of bytes are transmitted over an I2C bus between a master device and a slave device at address x37. By analogy, you can think of DDC is as a subclass of superclass I2C. DDC obeys the rules of I2C, but is more specific, e.g. it communicates only certain byte sequences are legal.

In practice, bit-banging is the responsibility of an I2C device driver. Note the use "an" rather than "the" - amdgpu, radeon, nvida, nouveau, i915, etc. each know how to do so for the devices they support. As a first order approximation, /dev/i2c provides a file system type interface that allows user space programs just read and write sequences of bytes, leaving the gory details to device driver writers. One of the reasons ddcutil has proven more robust than ddccontrol is that it hasn't tried to access the hardware directly, instead relying on the /dev/i2c interface.

As to your results: the failing combination is the Benq monitor, internal GPU, and i915 driver. Likely there's something marginal in the Benq's DDC implementation that only results in failure in that combination. That communication fails in seemingly different ways is a symptom of corrupted communication. Sometimes it is caught at a lower layer of the call stack, sometimes it is not apparent until the checksum is tested. Unfortunately, there's not much that you can do other than to swap hardware.

Finally, the softMCCS output shows no errors.

Sanford

On 3/26/20 6:32 PM, Arnoldas wrote:

Thanks a lot for detailed response. (Another long wall of text/logs incoming ...)

I managed to skim through few of the documents, but I'm still struggling with few concepts. Specifically, it's not quite clear to me how I2C bus is used to create DDC messages. I'll try to do more reading to understand this better. By the way, one of your links (https://app.box.com/s/vcocw3z73ta09txiskj7cnk6289j356b/file/93517210750/) seems to have died.

I don't have another monitor at the moment to test with i915 driver. However, I did try both outputs booted with live Ubuntu 18.04. I've also tried controlling the monitor via Raspberry Pi 3.

I've tried quite a few combinations and captured logs of almost everything. So, I hope you'll excuse me for far too many log files :) I thought it might be easier to ignore what is not relevant rather then trying to capture something again ...
What happens if you use
the Benq monitor on a Linux system with a driver other than i915?
First interesting observation - It seems to work all fine when controlling the monitor via dGPU using nouveau driver.

Second observation, it doesn't look like either DVI or HDMI inputs on the monitor are flawed in any way. I've tried swapping cables out (both are HDMI at the PC's end). Second time the HDMI input is connected to iGPU and it stops working, while DVI input connected to dGPU is functioning fine. Note, the OS was set to mirror displays and I was able to control it when either HDMI or DVI input was active.

Third, when running the same failing command multiple times, it seems to fail in different ways. Some examples with different /run/ numbers below.

I've tried repeating the commands one after another with couple of seconds in between. In my mind, it would suggests that some kind of registers are not being reset correctly after a failure. I suppose the i915 drivers would be at fault here.

Interestingly enough, I did try the sleep multiplier at couple suggested values as well as at much larger ones, but it seems to fail similarly although obviously it takes noticeably longer.

So, it seems like both DVI and HDMI inputs on monitor side are functioning and it's likely iGPU drivers at fault. Do you have any more ideas of what I could try or look at? I was thinking whether it's possible to just do some kind of bit-banging on I2C directly without relying on the kernel side driver at all.

Here is a batch of logs: i915 driver appears as i2c-18, and noveau dirver for nvidia card as i2c-6 Test 1, where iGPU is attached to DVI, and dGPU to HDMI ddcutil-interrogate.txt https://github.com/rockowitz/ddcutil/files/4390148/ddcutil-interrogate.txt ddcutil-env-verbose.txt https://github.com/rockowitz/ddcutil/files/4390150/ddcutil-env-verbose.txt Some working examples: ddcutil-i2c-6-hdmi-getvcp-0x60.txt https://github.com/rockowitz/ddcutil/files/4390188/ddcutil-i2c-6-hdmi-getvcp-0x60.txt ddcutil-i2c-6-hdmi-setvcp-0x60-0x11.txt https://github.com/rockowitz/ddcutil/files/4390187/ddcutil-i2c-6-hdmi-setvcp-0x60-0x11.txt ddcutil-i2c-6-hdmi-setvcp-0x60-0x03.txt https://github.com/rockowitz/ddcutil/files/4390189/ddcutil-i2c-6-hdmi-setvcp-0x60-0x03.txt And the requests going to DVI input via integrated graphics ddcutil-i2c-18-dvi-getvcp-0x60_run1.txt https://github.com/rockowitz/ddcutil/files/4390194/ddcutil-i2c-18-dvi-getvcp-0x60_run1.txt ddcutil-i2c-18-dvi-getvcp-0x60_run2.txt https://github.com/rockowitz/ddcutil/files/4390192/ddcutil-i2c-18-dvi-getvcp-0x60_run2.txt Then, trying noverify flag couple times, you'll see different number of retries and failures with different error codes between runs: ddcutil-i2c-18-dvi-setvcp-0x60-0x03_noverify_run1.txt https://github.com/rockowitz/ddcutil/files/4390204/ddcutil-i2c-18-dvi-setvcp-0x60-0x03_noverify_run1.txt ddcutil-i2c-18-dvi-setvcp-0x60-0x03_noverify_run2.txt https://github.com/rockowitz/ddcutil/files/4390205/ddcutil-i2c-18-dvi-setvcp-0x60-0x03_noverify_run2.txt ddcutil-i2c-18-dvi-setvcp-0x60-0x03_noverify_run3.txt https://github.com/rockowitz/ddcutil/files/4390206/ddcutil-i2c-18-dvi-setvcp-0x60-0x03_noverify_run3.txt Testing out sleep multiplier, again couple times with different failures: ddcutil-i2c-18-dvi-setvcp-0x60-0x03_sleep-8.0_run1.txt https://github.com/rockowitz/ddcutil/files/4390219/ddcutil-i2c-18-dvi-setvcp-0x60-0x03_sleep-8.0_run1.txt ddcutil-i2c-18-dvi-setvcp-0x60-0x03_sleep-8.0_run2.txt https://github.com/rockowitz/ddcutil/files/4390217/ddcutil-i2c-18-dvi-setvcp-0x60-0x03_sleep-8.0_run2.txt ddcutil-i2c-18-dvi-setvcp-0x60-0x03_sleep-8.0_run3.txt https://github.com/rockowitz/ddcutil/files/4390218/ddcutil-i2c-18-dvi-setvcp-0x60-0x03_sleep-8.0_run3.txt

Test 2, where iGPU is attached to HDMI and dGPU to DVI and then DVI input is fully functional: ddcutil-interrogate.txt https://github.com/rockowitz/ddcutil/files/4390225/ddcutil-interrogate.txt ddcutil-env-verbose.txt https://github.com/rockowitz/ddcutil/files/4390227/ddcutil-env-verbose.txt Functional DVI examples: ddcutil-i2c-6-dvi-getvcp-0x60.txt https://github.com/rockowitz/ddcutil/files/4390233/ddcutil-i2c-6-dvi-getvcp-0x60.txt ddcutil-i2c-6-dvi-setvcp-0x60-0x03.txt https://github.com/rockowitz/ddcutil/files/4390234/ddcutil-i2c-6-dvi-setvcp-0x60-0x03.txt ddcutil-i2c-6-dvi-setvcp-0x60-0x11.txt https://github.com/rockowitz/ddcutil/files/4390235/ddcutil-i2c-6-dvi-setvcp-0x60-0x11.txt ddcutil-i2c-6-dvi-getvcp-0x10_run1.txt https://github.com/rockowitz/ddcutil/files/4390236/ddcutil-i2c-6-dvi-getvcp-0x10_run1.txt ddcutil-i2c-6-dvi-getvcp-0x10_run2.txt https://github.com/rockowitz/ddcutil/files/4390237/ddcutil-i2c-6-dvi-getvcp-0x10_run2.txt Tries for 0x10 and 0x60 registers, with sleep multiplier example and also repeated, to show different failures: ddcutil-i2c-18-hdmi-getvcp-0x10_run1.txt https://github.com/rockowitz/ddcutil/files/4390248/ddcutil-i2c-18-hdmi-getvcp-0x10_run1.txt ddcutil-i2c-18-hdmi-getvcp-0x10_run2.txt https://github.com/rockowitz/ddcutil/files/4390249/ddcutil-i2c-18-hdmi-getvcp-0x10_run2.txt ddcutil-i2c-18-hdmi-getvcp-0x60_run1.txt https://github.com/rockowitz/ddcutil/files/4390250/ddcutil-i2c-18-hdmi-getvcp-0x60_run1.txt ddcutil-i2c-18-hdmi-getvcp-0x60_run2.txt https://github.com/rockowitz/ddcutil/files/4390251/ddcutil-i2c-18-hdmi-getvcp-0x60_run2.txt ddcutil-i2c-18-hdmi-setvcp-0x60-0x11_sleep-8.0_run1.txt https://github.com/rockowitz/ddcutil/files/4390252/ddcutil-i2c-18-hdmi-setvcp-0x60-0x11_sleep-8.0_run1.txt ddcutil-i2c-18-hdmi-setvcp-0x60-0x11_sleep-8.0_run2.txt https://github.com/rockowitz/ddcutil/files/4390253/ddcutil-i2c-18-hdmi-setvcp-0x60-0x11_sleep-8.0_run2.txt

For completeness to isolate any combination of problems between PC and monitor, I've also tried on Raspberry Pi.

Funny enough, I could not get HDMI input to work, while it worked fine when connected (with the same cable) to DVI. I suspect it is a separate issue. Logs are here as well, but error codes seem different to me which probably points to a different Pi specific issue.

Connected to DVI: ddcutil-interrogate.txt https://github.com/rockowitz/ddcutil/files/4390270/ddcutil-interrogate.txt ddcutil-env-verbose.txt https://github.com/rockowitz/ddcutil/files/4390271/ddcutil-env-verbose.txt ddcutil-i2c2-dvi-getvcp-0x10_run1.txt https://github.com/rockowitz/ddcutil/files/4390274/ddcutil-i2c2-dvi-getvcp-0x10_run1.txt ddcutil-i2c2-dvi-getvcp-0x60_run1.txt https://github.com/rockowitz/ddcutil/files/4390276/ddcutil-i2c2-dvi-getvcp-0x60_run1.txt ddcutil-i2c2-dvi-setvcp-0x60_0x03_run1.txt https://github.com/rockowitz/ddcutil/files/4390277/ddcutil-i2c2-dvi-setvcp-0x60_0x03_run1.txt ddcutil-i2c2-dvi-setvcp-0x60_0x11_run1.txt https://github.com/rockowitz/ddcutil/files/4390278/ddcutil-i2c2-dvi-setvcp-0x60_0x11_run1.txt And connected to HDMI input: ddcutil-interrogate.txt https://github.com/rockowitz/ddcutil/files/4390280/ddcutil-interrogate.txt ddcutil-i2c2-hdmi-getvcp-0x60_run2.txt https://github.com/rockowitz/ddcutil/files/4390281/ddcutil-i2c2-hdmi-getvcp-0x60_run2.txt ddcutil-i2c2-hdmi-getvcp-0x60_run3.txt https://github.com/rockowitz/ddcutil/files/4390282/ddcutil-i2c2-hdmi-getvcp-0x60_run3.txt ddcutil-i2c2-hdmi-setvcp-0x60_0x03_noverify_run1.txt https://github.com/rockowitz/ddcutil/files/4390283/ddcutil-i2c2-hdmi-setvcp-0x60_0x03_noverify_run1.txt ddcutil-i2c2-hdmi-setvcp-0x60_0x03_noverify_run2.txt https://github.com/rockowitz/ddcutil/files/4390284/ddcutil-i2c2-hdmi-setvcp-0x60_0x03_noverify_run2.txt ddcutil-i2c2-hdmi-setvcp-0x60_0x03_noverify_run3.txt https://github.com/rockowitz/ddcutil/files/4390285/ddcutil-i2c2-hdmi-setvcp-0x60_0x03_noverify_run3.txt ddcutil-i2c2-hdmi-getvcp-0x10_run1.txt https://github.com/rockowitz/ddcutil/files/4390286/ddcutil-i2c2-hdmi-getvcp-0x10_run1.txt ddcutil-i2c2-hdmi-getvcp-0x10_run2.txt https://github.com/rockowitz/ddcutil/files/4390287/ddcutil-i2c2-hdmi-getvcp-0x10_run2.txt ddcutil-i2c2-hdmi-getvcp-0x10_run3.txt https://github.com/rockowitz/ddcutil/files/4390288/ddcutil-i2c2-hdmi-getvcp-0x10_run3.txt ddcutil-i2c2-hdmi-getvcp-0x60_run1.txt https://github.com/rockowitz/ddcutil/files/4390289/ddcutil-i2c2-hdmi-getvcp-0x60_run1.txt ddcutil-i2c2-hdmi-getvcp-0x10_sleep-4_run1.txt https://github.com/rockowitz/ddcutil/files/4390292/ddcutil-i2c2-hdmi-getvcp-0x10_sleep-4_run1.txt ddcutil-i2c2-hdmi-getvcp-0x10_sleep-4_run2.txt https://github.com/rockowitz/ddcutil/files/4390290/ddcutil-i2c2-hdmi-getvcp-0x10_sleep-4_run2.txt ddcutil-i2c2-hdmi-getvcp-0x10_sleep-4_run3.txt https://github.com/rockowitz/ddcutil/files/4390291/ddcutil-i2c2-hdmi-getvcp-0x10_sleep-4_run3.txt

And lastly,
Is there anything interesting in the softMCCS DDC/CI communication
log?
Not really sure how to interpret the log. Seems like all messages are going through, but I am not sure what data is being printed in there. In this log I've tried adjusting the brightness and switched the input. softMCCS_log.txt https://github.com/rockowitz/ddcutil/files/4390314/softMCCS_log.txt

I do appreciate your time and I hope it's not too much information to scan through. If I can present it somehow better, please do let me know. Likewise, if there is something specific I could dig in more better understand the problem - I'm happy to go away do my reading first.

Thanks, Arnoldas

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

Mar 27 '20 23:03 rockowitz

There have recently been 2 reports (by @slavov-viii on issue #125 and @kowalc0 on issue #67) that setting brightness (feature x10) fails on Benq and Lenovo monitors when Dynamic Contrast Range is enabled. I suggest you try disabling DCR and/or Low Blue Light and see if this affects your ability to set brightness using ddcutil.

Jul 05 '20 02:07 rockowitz