rockowitz
Eizo ColorEdge CS2731 over USB: "Display not found"
I have a CS2731 connected to my laptop via USB. It uses DisplayPort over USB-C.
When I try to control it with ddcutil it says Display not found (see below).
$ ddcutil --version
ddcutil 2.2.0
Copyright (C) 2015-2025 Sanford Rockowitz
License GPLv2: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ddcutil usbenv | grep -i eizo
Bus 003 Device 052: ID 056d:4048 EIZO Corp. EIZO USB HID Monitor
Device /dev/usb/hiddev1, devnum.busnum: 3.52, vid:pid: 056d:4048 - EIZO EIZO USB HID Monitor
$ ddcutil capabilities --usb 3.52
Display not found
$ ddcutil getvcp known --usb 3.52
Display not found
$
When I connect the display to a MacBook with the proprietary ColorNavigator software installed, I can verify that brightness control is working via USB.
If you want, I can try to install ColorNavigator in a Windows VM to help reverse engineer the Eizo protocol (if it doesn't follow the MCCS standard).
Output of sudo ddcutil usbenvironment --verbose attached.
Please submit the output of sudo ddcutil detect --enable-usb --verbose and sudo ddcutil interrogate --enable-usb --verbose. Note the --enable-usb option - by default ddcutil commands do not look for VCP communication over USB.
Please submit the output of the following command: sudo getvcp 10 --trace usb --hiddev 1
Also, looking at the detect output, the monitor is found on bus /dev/i2c-1. The error DDCRC_DDC_DATA indicates that corrupted data packets are being read from the monitor. Sometimes this can be corrected by increasing the time that ddcutil sleeps betwen sending a request packet and attempting to read the reply packet. Try using the command ddcutil detect --verbose --enable-usb --sleep-multiplier 3.0
Please execute the following:
ddcutil getvcp 10 --enable-usb --hiddev1 --trcfrom get_hiddev_edid_with_fallback
ddcutil detect --verbose --ddcdata --sleep-multiplier 2.0
Curiously, your detect output locates the laptop display's EDID at both /dev/i2c-5 and /dev/-i2c9. I've seen this double /dev/i2c assignment before, but always in the context of docking stations. In the latter case it's an artifact of how Multi-Stream Transport is implemented. freedesktop.org i915 issue 3605 - Same MST display appears as 2 /dev/i2c devices explains why. In this case I have no explanation for the double assignment, but since laptop displays don't implement DDC, it doesn't matter.
Here the log for both commands. The first one ends up in a crash; I managed to get a backtrace from gdb. (I use ddcutil release tagged v2.2.0).
Re the first command, you faithfully executed my typo. The command should have been ddcutil getvcp 10 --enable-usb --hiddev 1 --trcfrom get_hiddev_edid_with_fallback, i.e. with a space between "hiddev" and "1". So please run that command.
The crash has me puzzled. When I execute the invalid command here, with branch 2.2.1-dev on Ubuntu 24.10, I get the expected error message "Unknown option --hiddev1". In your case no message appears to be emitted, and the invalid free() is of the error msg struct returned by glib's parser.
Re the second command, the feature reply packets seem to be random bytes. Normally, I can make out some fragment of a proper reply when the error is DDCRC_DDC_DATA. It's as if sending the request packet succeeds, but the monitor never puts a reply packet on the bus. I can't find any mention in the Eizo display documentation as to whether it supports DDC/CI. Perhaps it supports communication with the monitor's Virtual Control Panel only over USB, though the fact that the DDC/CI request packets succeed suggest it does. The only thing I can suggest at this point is to try using a HDMI connection to the monitor instead of using the Type-C connector.
I checked out and built the 2.2.1-dev branch. My laptop is on Ubuntu 22.04.5 LTS if that matters.
With the typo in the commandline I still get the same crash. With the corrected commandline it does this:
$ sudo ddcutil getvcp 10 --enable-usb --hiddev 1 --trcfrom get_hiddev_edid_with_fallback
(get_hiddev_edid_with_fallback ) Starting busnum=3, devnum=14, vendor=-x0000056d, product=0x00004048
(get_hiddev_edid_with_fallback ) hiddev_get_edid() returned (nil)
(get_hiddev_edid_with_fallback ) hiddev_get_multibyte_value_by_ucode() returned (nil)
(get_fallback_hiddev_edid ) Starting busnum=3, devnum=14, vendor=-x0000056d, product=0x00004048
(get_fallback_hiddev_edid ) *** Special fixup for Eizo monitor ***
(get_eizo_model_sn_by_report ) Starting
(find_eizo_model_sn_report ) Starting
(hiddev_get_device_info ) Starting.
(hiddev_get_device_info ) Done. Returning: OK(0): success
(find_eizo_model_sn_report ) Done Returning: (nil)
(get_eizo_model_sn_by_report ) Done Returning: (nil)
(get_fallback_hiddev_edid ) Done Returning: (nil)
(get_hiddev_edid_with_fallback ) Done Returning: (nil)
Monitor on device /dev/usb/hiddev2 reports no EDID or has invalid EDID. Ignoring.
Display not found
Here's what the output is showing.
(We've already determined that the monitor claims to comply with the HID Monitor Control Class Spec.)
ddcutil first tries to read the EDID in the manner prescribed by the spec. It actually tries to do this in two different ways and checks them for consistency. Both fail. So get_fallback_hiddev_edid() is called.
get_fallback_hiddev_edid searches through the EDIDs that have already been read using DDC. It first tries using device information for hiddev1. This fails. However, based on the vendor id, we know this an Eizo monitor. During development, I found that that an alternative way to get the EDID was possible for Eizo monitors. There's an Eizo specific USB report that returns the model and serial number. Unfortunately, for your monitor this doesn't work either.
Since ddcutil can't find an EDID for the device, it decides that hiddev1 is not a monitor. I'll consider whether creating a dummy EDID in this situation might provide a workaround, but for now I'm afraid we're stuck.