Unable to control BenQ GL2250HM monitor #115
Comments
|
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.
1) The problem is in DDC communication. Feature x60 may be problematic,
but that is not relevant here.
2) 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).
3) ddcutil uses the dev-i2c userspace driver. The kernel side of the
driver in turn uses the video driver.
4) 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.
5) 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.
6) 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
7) 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.
8) 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
<#115>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3RFMHPXNZCNTVRYTA3RJCROLANCNFSM4LSTOBGQ>.
|
rockowitz
added
i915
|
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 ...
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: Test 2, where iGPU is attached to HDMI and dGPU to DVI and then DVI input is fully functional: 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: And lastly,
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. 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, |
|
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
<#115 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADMGY3SKMOIQYXXR5PX4KULRJPJZDANCNFSM4LSTOBGQ>.
|
|
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. |
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:
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
The text was updated successfully, but these errors were encountered: