Benq EX3210U either non responsive or invalid feature flag in DDC reply packet. #476
Comments
|
There are impressively many things going on in your very thorough report. Let me make an initial cut at addressing them. First, to rule out ddcutil's involvement in the original issue of KDE not outputting to the monitor if it wakes up with a frame rate higher than 30fps, I assume you've set environment variable POWERDEVIL_NO_DDCUTIL=1 to completely disable powerdevil's use of libddcutil. More granualarly, you can disable libddcutil's display change detection by setting option: --disable-watch-displays in configuration file $HOME/.config/ddcutil/ddcutilrc, or tell both command line ddcutil and shared library libddcutil to ignore the Benq display using option --ignore-mmid BNQ-BenQ_EX3210U-32678. (The option was previously ambiguously named --ignore-ddc. In the detect output for the second case where the computer is restarted with the monitor connected, the telling line in the output is "I2C address 0x37 (DDC) responsive: false". In that situation, issue command **i2cdetect -y 17", which shows which slave addresses are active on the I2C bus. Slave address x50 (EDID) should be reported. If slave address x37 (DDC) is not, the problem is entirely in the province of the driver and monitor, ddcutil has no involvement. The laptop display appearing at two different I2C addresses has been seen before in the context of docking stations. (See The messages regarding slave address x37 not being responsive for the laptop display should more clearly and simply state that laptop displays do not support DDC/CI, which is what is usually stated. It turns out that determining what is a laptop display can be ambiguous. (See freedesktop.org issue #10389, DRM connector for external monitor has name card1-eDP-1). I'll rework the test. In any case, it's simply a matter of a better informational message. Regading interrogate hanging, running it with valgrind (valgrind ddcutil interrogate) or with asan should give more information on what is happening. (To use asan, you need to have asan installed and use configure option --enable-asan before building ddcutil.) I look forward to learning what you find. |
|
Thanks, I have been looking at this for a while. I have, indeed got POWERDEVIL_NO_DDCUTIL=1 in /etc/environment. Of course, I don't really like that, because I would like ddcutil to properly detect and manage this display. Which is the reason we are poking at it now, I guess.
So, I have started up the computer with the monitor powered up, and indeed it is showing the laptop's panel on /dev/i2c-3 and /dev/i2c-7 The Benq shows up on /dev/i2c-17, and claims to be unresponsive. I don't know what the above means, hopefully you can shed some light on that? Valgrind is completely not happy: In Arch, I don't see a package with "asan" in the name. Could you please provide a link to the source of that package so I can hunt it down? |
|
I did manage to get a full interrogation. I guess I was just not patient enough last time. 2024-12-12_DDCUtil_interrogate_fresh_powerup_complete.txt For completeness, I have also run a ddcutil interrogate after a warm boot: So, after a warm boot with the monitor on, this monitor now claims to not support DDC. Also, the remote for it does not work. In the past I have noticed some very weird issues, where it would flicker heavily at high refresh rates. Even turning off and unplugging everything and starting up again this flickering continued until I started playing a bit of No Mans Sky, when it stopped. This leads me to believe that there is something not working properly and giving the monitor signals which completely confuses it. One other thing that I notice with this monitor is that it is very slow to display an image once it is plugged in and has a valid HDMI signal sent to it. |
|
I'm starting to suspect a driver issue. If there is some way to completely rule out ddcutil, then I can follow the rabbit hole a bit deeper and go pester the folks at nVidia. |
|
Re the docking station, I was just pointing to that as another situation in which the monitor appears on multiple /dev/i2c devices. I have a hunch that, and it's only that, having 2 gpus in the system uses some of the same logic as docking stations. i2cdetect is s a basic system utility independent of ddcutil. It comes from package i2c-tools. Command i2cdetect -y 17 scans /dev/i2c-17 to see which slave addresses are responsive. In this case it's slave addresses x3A, x3E, x50, x54, and x58. Slave address x50 is used to read the EDID; since it's responsive we know that there's a monitor connected. Slave address x37 is used for DDC/CI communication; since it's not responsive DDC/CI communication with the monitor is impossible. There's nothing ddcutil can do about it. It's a driver/monitor issue. Re valgrind, I've never seen output like that. but since the problem was imply that ddcutil interrogate was not allowed to run to completion, there's no reason to explore that more. Re asan, FWIW on the Fedora system where I'm current;y running the package name is "libasan". I would be very surprised if asan does not exist on Arch. |
rockowitz
added
monitor specific
|
Hi there! Thank you so much for coming back to me on this issue. In response to the DDC/CI support disappearing when the monitor is connected and powered upon boot, I have filed this on the nVidia forums. On Arch libasan is part of gcc-libs, and installed on any Arch system that has GCC installed. We can almost wrap this up, but one curiosity remains from my side. When you look at the ddcutil interrogate output that was obtained with the monitor was adressable, there are a lot of VCP codes that are listed as unsupported VCP codes. Does this mean that the code is not implemented on this monitor, or that it is implemented on this monitor and ddcutil just does now know what to do with it? In fact, when you scan through |
|
VCP feature codes are 1 byte values, from 0 to 255. The Monitor Control Command Set spec specifies a subset of these. For example feature x10 is brightness. No monitor implements all the features in the spec. Features xE0..xFF are reserved for manufacturer use. It is also possible that a monitor uses an undefined feature in some way. The features that given monitor supports are returned as a string and interpreted by command ddcutil capabilities. There are a few things of interest. The monitor uses features xE6, XF4, xFD, xFe, xFF in the manufacturer reserved range. ddcutil does not know how to interpret these. There are several features codes that are responsive even though they are defined in the capabilities string. For many features that represet discrete options rather than continuous values, the capabilities defines the recognized values. For example feature x60 (Input Source) has defined values of x0F (Displayport-1), x11 (HDMI-1) and x12(HDMI-2). In some cases, such as feature xDC (Display Mode), the monitor reports using several values that are not defined in the MCCS spec. So the bottom line is that there's nothing particularly unusual about the monitor in this regard. For details on the relevant specs, see page Reference Documents on www.ddcutil.com. |
|
Thanks again for the prompt and very detailed response. I'll see if I can pester the manufacturer of the monitor to give me some documentation on what those codes mean, and I'll post it here if you can find some use for it. |
Hi there!
I've been seeing an issue with my external monitor. It's a fairly new and expensive Benq EX3210U monitor, alledgedly capable of 4K@144Hz in HDR. The best I have seen is 4K@120fps in HDR and SDR, but that might be a different discussion.
This monitor is connected via a HDMI 2.1 cable to the HDMI port of my Asus ROG Strix Scar laptop. It is an Advanced Optimus MUX type laptop, and apparently the HDMI port is directly wired to the nVidia RTX 4090 that is the laptops dGPU.
The operating system is Arch Linux, fully up to date.
The issue that I am seeing I have reported to the KDE bug tracker.
https://bugs.kde.org/show_bug.cgi?id=496631
The reason that I am here, is that there seems to be some inconsistency in the way that ddcutil is detecting this display.
If the monitor is powered down, unplugged from power and the HDMI port, and then plugged in sudo ddcutil detect --verbose --ddc --sleep-multiplier 20 returns:
If, however, this computer is restarted with the monitor connected, it returns this:
This may or may not be related to my original issue of KDE not outputting to this monitor if it wakes up with a defined frame rate higher than 30fps, but it is something that is a little interesting to me.
For completeness, I am also attaching the output of sudo ddcutil interrogate when the monitor is freshly woken up and actually responds to ddcutil. It seems to hang on my system, so it might be incomplete.
2024-12-10_DDCUtil_interrogate_Fresh_Powerup.txt
Any help in figuring out what is going on and which direction to look would be awesome. I have been in contact with BenQ to see if I can get a firmware update for this monitor, but so far we have been unable to update this monitor.
The text was updated successfully, but these errors were encountered: