EIZO EV3237 DDC Communication failed

[U1F984]

I'm having issues with controlling the EV3237 monitor. I'm connected over HDMI (as Displayport DDC is not supported) and can't talk to the monitor. EIZO doesn't have any info in the manual about how to turn on/off DDC, but it claims it has it.

I've attached the report from ddcutil interrogate. report.txt

Thanks for this awesome tool!

[rockowitz]

Leo,

It looks like the monitor (found on /dev/i2c-0) is connected to on-CPU Intel video, not to the add-on Nvidia card. Is this correct? Please confirm this.

Alternatively, many EIZO monitors support USB communication. Have you tried this? Please run "ddcutil usbenvironment --verbose" and send the output. Thanks.

Sanford

On 07/08/2018 04:53 AM, Leo Tietz wrote:

I'm having issues with controlling the EV3237 monitor. I'm connected over HDMI (as Displayport DDC is not supported) and can't talk to the monitor. EIZO doesn't have any info in the manual about how to turn on/off DDC, but it claims it has it.

I've attached the report from ddcutil interrogate. report.txt https://github.com/rockowitz/ddcutil/files/2173524/report.txt

Thanks for this awesome tool!

— 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/55, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbmHpG_sJYT6b30u30ZeQpl8DLzUUks5uEciVgaJpZM4VGpiL.

[U1F984]

Hey Sanford,

that is correct. The nvidia card is used in PCI pass-through to a VM. I don't have the necessary USB cable available, I'll get one tomorrow and test with that.

Thanks, Leo

[U1F984]

Tested it today, got:

Output level:               Verbose
Reporting DDC data errors:  false
Trace groups active:        none
Traced functions:           none
Traced files:               none
Force I2C slave address:    false

(get_multibyte_value_by_uref_multi) ioctl(HIDIOCGUSAGES) failed.  errno=22: Invalid argument
(get_multibyte_value_by_uref_multi) ioctl(HIDIOCGUSAGES) failed.  errno=22: Invalid argument
ddcutil: data_structures.c:874: buffer_free: Assertion `buffer' failed.
Aborted

The monitor's usb hub is detected though:

root@leo-pc:~# lsusb | fgrep -i eizo
Bus 001 Device 027: ID 056d:4000 EIZO Corp.

[rockowitz]

Leo,

Proceeding on 2 communication paths, I2C and USB.

I2C

What I'm seeing is that all the DDC I2C requests are turning all bytes

0. Unfortunately, this is an ambiguous response. It may indicate a communication error, it can also be a non-standard monitor response to indicate "unsupported feature".

Please run the following command (assuming the monitor is still at /dev/i2c-0) and send the output. It will be quite large.

ddcutil getvcp 10 --bus 0 --trace ddc --trace i2c --ddc

Do you have the ability to connect a different monitor to the computer, and/or attach the monitor to a different Linux system to try to isolate the problem?

USB

It looks like an error in some Eizo specific USB code for detecting monitor model and serial number, but it's hard to say for certain without inserting debug code. I have access to a handful of Eizo models at the Rochester Institute of Technology, but not your specific model.

I see that you're running ddcutil 0.8.6, which ships with Ubuntu 18.04.
The current version is 0.9.1. Would you be comfortable building a special debug version if I give you a tarball?

Sanford

On 07/10/2018 01:47 PM, Leo Tietz wrote:

Tested it today, got:

|Output level: Verbose Reporting DDC data errors: false Trace groups active: none Traced functions: none Traced files: none Force I2C slave address: false (get_multibyte_value_by_uref_multi) ioctl(HIDIOCGUSAGES) failed. errno=22: Invalid argument (get_multibyte_value_by_uref_multi) ioctl(HIDIOCGUSAGES) failed. errno=22: Invalid argument ddcutil: data_structures.c:874: buffer_free: Assertion `buffer' failed. Aborted |

The monitor's usb hub is detected though:

|root@leo-pc:~# lsusb | fgrep -i eizo Bus 001 Device 027: ID 056d:4000 EIZO Corp. |

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/55#issuecomment-403909106, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbnW-P1rqxNs9olv-R8rBo7Qw12nWks5uFOivgaJpZM4VGpiL.

[U1F984]

Hey Sanford,

sorry for the late reply. I've attached i2c.txt as the output from the first command you sent. Testing a different monitor would be possible as well, just some effort.

Thanks for offering to debug this further with a special debug version, I'd love to try it.

Regards, Leo

[rockowitz]

Leo,

I've uploaded a special debug version of ddcutil to http://www.ddcutil.com/tarballs/ddcutil-0.9.2.tar.gz

For instructions on building from source, see: http://www.ddcutil.com/building/

I believe I've fixed the cause of the abort when running ddcutil usbenvironment --verbose

Please run the following commands and send the output:

ddcutil detect --verbose ddcutil usbenvironment --verbose

The above addresses USB communication. As I noted, all I2C requests return responses with all bytes 0. Besides swapping monitors on Linux systems, if you can attach the monitor to a Windows system, enTech's softMCCS utility (https://www.entechtaiwan.com/lib/softmccs.shtm) exercises DDC/CI communication and may give a hint as to where the problem lies. (enTech makes chips for DDC/CI communication.)

Thanks for helping to diagnose these issues.

Sanford

On 07/14/2018 06:44 AM, Leo Tietz wrote:

Hey Sanford,

sorry for the late reply. I've attached i2c.txt https://github.com/rockowitz/ddcutil/files/2194882/i2c.txt as the output from the first command you sent. Testing a different monitor would be possible as well, just some effort.

Thanks for offering to debug this further with a special debug version, I'd love to try it.

Regards, Leo

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/55#issuecomment-405015084, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbqPszMwXuav0q2ciPKbulM5Eb_SOks5uGctzgaJpZM4VGpiL.

[rockowitz]

Leo,

I've updated http://www.ddcutil.com/tarballs/ddcutil-0.9.2.tar.gz with some additional diagnostics turned on.

Sanford

On 07/14/2018 02:57 PM, Sanford Rockowitz wrote:

Leo,

I've uploaded a special debug version of ddcutil to http://www.ddcutil.com/tarballs/ddcutil-0.9.2.tar.gz

For instructions on building from source, see: http://www.ddcutil.com/building/

I believe I've fixed the cause of the abort when running ddcutil usbenvironment --verbose

Please run the following commands and send the output:

ddcutil detect --verbose ddcutil usbenvironment --verbose

The above addresses USB communication. As I noted, all I2C requests return responses with all bytes 0. Besides swapping monitors on Linux systems, if you can attach the monitor to a Windows system, enTech's softMCCS utility (https://www.entechtaiwan.com/lib/softmccs.shtm) exercises DDC/CI communication and may give a hint as to where the problem lies. (enTech makes chips for DDC/CI communication.)

Thanks for helping to diagnose these issues.

Sanford

On 07/14/2018 06:44 AM, Leo Tietz wrote:

Hey Sanford,

sorry for the late reply. I've attached i2c.txt https://github.com/rockowitz/ddcutil/files/2194882/i2c.txt as the output from the first command you sent. Testing a different monitor would be possible as well, just some effort.

Thanks for offering to debug this further with a special debug version, I'd love to try it.

Regards, Leo

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/55#issuecomment-405015084, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbqPszMwXuav0q2ciPKbulM5Eb_SOks5uGctzgaJpZM4VGpiL.

[U1F984]

I've attached the output of both commands:

detect.txt usb.txt

[rockowitz]

Leo,

Thanks for sending the USB output. The problem is that Eizo is using manufacturer-specific usage codes for monitor communication instead of those defined in the USB Monitor Control Class Specification. So ddcutil doesn't know how to interpret them. ddcutil's error handling needs to be cleaned up, but absent a spec for what Eizo is doing or some major reverse engineering that's as much as can be done.

That leaves the DDC/CI I2C communication. What's odd is that the monitor is responsive to I2C bus address x37, which is used for DDC/CI, but as I noted earlier the response to every request for a feature value is a sequence of 0 bytes. The best way to test for DDC/CI compliance is using enTech's softMCCS on Windows.

Wish I had better news.

Sanford

On 07/15/2018 01:14 PM, Leo Tietz wrote:

I've attached the output of both commands:

detect.txt https://github.com/rockowitz/ddcutil/files/2195933/detect.txt usb.txt https://github.com/rockowitz/ddcutil/files/2195934/usb.txt

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/55#issuecomment-405104848, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbhP3FMXTJ-okyTD6h__edCETLa1Tks5uG3hogaJpZM4VGpiL.

[U1F984]

Hey Sanford,

do you know if it is possible to run softMCCS in Wine or similar?

Regards,

Leo

[rockowitz]

I have not tested, but here's what I would expect:

In a VM using the usual VM video drivers: No, the I2C bus is not virtualized.

In a VM with a dedicated video card using the actual Windows video driver. Should work.

Wine: Probably not. I don't know if softMCCS is using the Windows DDC API or is doing something more low level. Given the purpose of softMCCS, I would expect the latter. I'd be surprised if Wine provides the required services.

Sanford

On 07/18/2018 03:16 PM, Leo Tietz wrote:

Hey Sanford,

do you know if it is possible to run softMCCS in Wine or similar?

Regards,

Leo

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/55#issuecomment-406043782, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbnVI9xuMVBfvEs5eHugovsBiZGaJks5uH4mQgaJpZM4VGpiL.

[rockowitz]

I have installed and run softMCCS in Wine. As expected, it reports an unhandled privileged instruction and fails to detect any monitors, i.e. it's using low level Windows services that Wine does not provide.

On 07/18/2018 03:16 PM, Leo Tietz wrote:

Hey Sanford,

do you know if it is possible to run softMCCS in Wine or similar?

Regards,

Leo

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/55#issuecomment-406043782, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbnVI9xuMVBfvEs5eHugovsBiZGaJks5uH4mQgaJpZM4VGpiL.

[U1F984]

Hey,

sorry for the long delay. It seems like contrary to their claims in marketing material, they do not support DDC communication. I've attached the monitor both over HDMI and DP2 (I attached HDMI later as seen in the log) and it doesn't appear to work. Here's the log from softmccs: softMCCS.log

Since that route is unavailable, the only route available is reverse engineering the usb communication. While I'd be happy to use their screen control software and record usb traffic + what I am doing to aid this effort I do feel it would be an unreasonable burden on you to reverse engineer it all just for this single monitor (or all monitors controllable by Screen InStyle, if they use the same protocol). What would interest me though is if you could point me to a resource to do usb capturing and replay; the EIZO software (Screen InStyle) offers to configure hotkeys to switch input sources; if I could maybe capture the traffic when a switch command is issued I could dumbly replay this on Linux to get most of what I want (software KVM switch).

Thanks,

Leo

[rockowitz]

On 07/22/2018 07:00 AM, Leo Tietz wrote:

Hey,

sorry for the long delay. It seems like contrary to their claims in marketing material, they do not support DDC communication. I've attached the monitor both over HDMI and DP2 (I attached HDMI later as seen in the log) and it doesn't appear to work. Here's the log from softmccs: softMCCS.log https://github.com/rockowitz/ddcutil/files/2216914/softMCCS.log

Looks pretty clear. It's odd that the DDC slave address (x37) is active, even though DDC/CI is unsupported, but that seems to be the case.

Since that route is unavailable, the only route available is reverse engineering the usb communication. While I'd be happy to use their screen control software and record usb traffic + what I am doing to aid this effort I do feel it would be an unreasonable burden on you to reverse engineer it all just for this single monitor (or all monitors controllable by Screen InStyle, if they use the same protocol). What would interest me though is if you could point me to a resource to do usb capturing and replay; the EIZO software (Screen InStyle) offers to configure hotkeys to switch input sources; if I could maybe capture the traffic when a switch command is issued I could dumbly replay this on Linux to get most of what I want (software KVM switch).

It's been a while since I looked into USB protocol analyzers. IIRC, the good ones were hardware based, and not cheap. I imagine there's some switch available to Windows device driver developers for turning on USB tracing.

InStyle could conceivably be used within a VM, but I imagine you'd need to have USB ports dedicated to the VM, not virtualized.

Thanks,

Leo

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/55#issuecomment-406857567, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbiu3KsTWZ2NK_CMCKSGEXzdupB1eks5uJFtegaJpZM4VGpiL.

[U1F984]

Too bad that you don't know of good software analyzers; would have been interesting to investigate that. I've created a workaround for now, executing InStyle in the VM and issuing the hotkeys via a webserver written in C#, also running in the VM. While it doesn't work very reliable, its mostly functional and does the job ok-ish. I'm closing the issue since I don't think there's too much we can do now.