ddcutil detect => Invalid display + DDC communication failed

[fm99]

I have a Linux PC and a Raspberry Pi 2 attached to one monitor. The Linux PC is connected to the DisplayPort interface and the Raspberry Pi to the HDMI interface.

I'm looking for a CLI solution for switching interfaces. Google search pointed me to ddccontrol and ddcutil. Having spent two hours playing with both tools and reading about them, I come to the conclusion that ddcutil is the more promising way to go ("ddcutil setvcp D0 DPDDC-B" might do the trick).

My understanding is that ddcutil is still under development and that certain devices/features are not supported yet. When I run 'ddcutil detect --verbose' on my Linux PC the output contains a couple of warnings and errors:

• "Open failed for /dev/usb/hiddev0: errno=EACCES(13): Permission denied"
• "Invalid display"
• "DDC communication failed"
• "No active displays found"

Perhaps someone more familiar with ddcutil can help and interpret the output. Is my monitor and/or graphic card supported? Should I spend more time investigating a ddcutil-based solution? - Thank you for any help.

The full output of 'ddcutil detect --verbose' on my Linux PC is as follows:

$ ddcutil detect --verbose
Output level:               Verbose
Reporting DDC data errors:  false
Trace groups active:        none
Force I2C slave address:    false

Open failed for /dev/usb/hiddev0: errno=EACCES(13): Permission denied
Invalid display
   I2C bus:             /dev/i2c-6
   Supports DDC:        true
      I2C address 0x37 (DDC)  present: true 
      I2C address 0x50 (EDID) present: true 
      /sys/bus/i2c/devices/i2c-6/name: DPDDC-B
   EDID synopsis:
      Mfg id:           AOC
      Model:            Q2775
      Serial number:    KKRG3JA001207�
      Manufacture year: 2016
      EDID version:     1.4
      Product code:     0x2775 (10101)
      Extra descriptor: 
      White x,y:        0.313, 0.329
      Red   x,y:        0.660, 0.331
      Green x,y:        0.300, 0.632
      Blue  x,y:        0.148, 0.055
   EDID hex dump:
              +0          +4          +8          +c            0   4   8   c   
      +0000   00 ff ff ff ff ff ff 00 05 e3 75 27 b7 04 00 00   ..........u'....
      +0010   0b 1a 01 04 b5 3c 22 78 3a 3f 05 a9 54 4c a1 26   .....<"x:?..TL.&
      +0020   0e 50 54 bf ef 00 d1 c0 b3 00 95 00 81 80 81 40   .PT............@
      +0030   81 c0 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20   ......V^....)P0 
      +0040   35 00 55 50 21 00 00 1e 00 00 00 fd 00 32 4c 1e   5.UP!........2L.
      +0050   63 1e 01 0a 20 20 20 20 20 20 00 00 00 fc 00 51   c...      .....Q
      +0060   32 37 37 35 0a 20 20 20 20 20 20 20 00 00 00 ff   2775.       ....
      +0070   00 4b 4b 52 47 33 4a 41 30 30 31 32 30 37 01 c6   .KKRG3JA001207..
   DDC communication failed

No active displays found

[rockowitz]

On 02/25/2017 04:02 PM, fm99 wrote: I have a Linux PC and a Raspberry Pi 2 attached to one monitor. The Linux PC is connected to the DisplayPort interface and the Raspberry Pi to the HDMI interface. I'm looking for a CLI solution for switching interfaces. Google search pointed me to ddccontrol and ddcutil. Having spent two hours playing with both tools and reading about them, I come to the conclusion that ddcutil is the more promising way to go ("ddcutil setvcp D0 DPDDC-B" might do the trick).

This should work. But keep in mind that when switching from the PC to Pi the command will have to come from ddcutil on the PC, and when switching from Pi to PC the command will have to come from ddcutil on the Pi. Second, the setvcp command only takes numeric values as arguments. To see the values for feature D0, issue the command: ddcutil vcpinfo d0 --verbose Assuming you want to switch to the second HDMI connector, the command would be ddcutil setvcp d0 x12

My understanding is that ddcutil is still under development and that certain devices/features are not supported yet. When I run 'ddcutil detect --verbose' on my Linux PC the output contains a couple of warnings and errors: "Open failed for /dev/usb/hiddev0: errno=EACCES(13): Permission denied" "Invalid dislay"

This error message is a bit of red herring. Some high end monitors use USB instead of or in addition to DDC for communicating the Monitor Control Command Set (MCCS). The USB interface presents as a USB Human Interface Device, so ddcutil checks the hiddev devices on the system. The current development tree contains additional messages to make it clearer that this message is benign (unless, of course, you have a monitor that communicates using USB).

"DDC communication failed" "No active displays found"

Now we've come to the interesting problem. Why is DDC communication failing? Try running the command: ddcutil environment This checks for common configuration issues. If the diagnostic messages don't point you to a solution, run the following commands and send me the output: ddcutil detect --verbose --ddc --force-slave-address ddcutil environment --verbose Please include the output as attachments rather than inline as it's easier for me to work with. Sanford

…

Perhaps someone more familiar with the ddcutil can help and interpret the output. Is my monitor and/or graphic card supported? Should I spend more time investigating a ddcutil-based solution? - Thank you for any help. The full output of 'ddcutil detect --verbose' on my Linux PC is as follows: |$ ddcutil detect --verbose Output level: Verbose Reporting DDC data errors: false Trace groups active: none Force I2C slave address: false Open failed for /dev/usb/hiddev0: errno=EACCES(13): Permission denied Invalid display I2C bus: /dev/i2c-6 Supports DDC: true I2C address 0x37 (DDC) present: true I2C address 0x50 (EDID) present: true /sys/bus/i2c/devices/i2c-6/name: DPDDC-B EDID synopsis: Mfg id: AOC Model: Q2775 Serial number: KKRG3JA001207� Manufacture year: 2016 EDID version: 1.4 Product code: 0x2775 (10101) Extra descriptor: White x,y: 0.313, 0.329 Red x,y: 0.660, 0.331 Green x,y: 0.300, 0.632 Blue x,y: 0.148, 0.055 EDID hex dump: +0 +4 +8 +c 0 4 8 c +0000 00 ff ff ff ff ff ff 00 05 e3 75 27 b7 04 00 00 ..........u'.... +0010 0b 1a 01 04 b5 3c 22 78 3a 3f 05 a9 54 4c a1 26 .....<"x:?..TL.& +0020 0e 50 54 bf ef 00 d1 c0 b3 00 95 00 81 80 81 40 .PT............@ +0030 81 c0 01 01 01 01 56 5e 00 a0 a0 a0 29 50 30 20 ......V^....)P0 +0040 35 00 55 50 21 00 00 1e 00 00 00 fd 00 32 4c 1e 5.UP!........2L. +0050 63 1e 01 0a 20 20 20 20 20 20 00 00 00 fc 00 51 c... .....Q +0060 32 37 37 35 0a 20 20 20 20 20 20 20 00 00 00 ff 2775. .... +0070 00 4b 4b 52 47 33 4a 41 30 30 31 32 30 37 01 c6 .KKRG3JA001207.. DDC communication failed No active displays found | — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbunHmXRH-my4TwZ6Bnhh2ZAXfzVKks5rgJbbgaJpZM4MMIzn>.

[fm99]

Hi Sanford

Thank you for looking at my problem.

Both 'ddcutil setvcp d0 x11' and 'ddcutil setvcp d0 x12' give me the error message "Invalid display number".

Please find attached the output of the commands you have been asking for (including also the result of 'ddcutil interrogate'). The output looks fairly "normal" and "unsuspicious" to me. Being not an expert, I can only guess what might be wrong or missing. Maybe I need to load more I2C kernel modules (i2c_dev, i2c_piix4)?
ddcutil environment.txt
ddcutil detect --verbose --ddc --force-slave-address.txt
ddcutil environment --verbose.txt
ddcutil interrogate.txt

[rockowitz]

Well, this is looking interesting. Thanks for bringing this situation to my attention. First off, "ddcutil setvcp" will not work until the monitor detection issue is resolved. What's peculiar is that the raw monitor detection code in ddcutil environment is able to establish DDC communication. So something weird is going on. It looks like you're using an HP desktop with a Xeon processor having integrated graphics. Is that correct? Model? Is there a secondary video card in the system? If this happens to be a laptop, is the monitor connected through a docking station? Please try the following commands and send me the output: ddcutil detect --verbose --trace ddc --trace i2c --stats ddcutil getvcp 10 --verbose --trace ddc --trace i2c --stats ddcutil getvcp 10 --bus 6 --force --verbose --trace ddc --trace i2c --stats The final command may crash ddcutil. The --force option ignores various internal error conditions, and is intended for diagnostic purposes. Lastly, there is no need to load i2c_dev. The environment command reports that it is built into the kernel. i2c_piix4 is used for I2C devices that are also SMBus devices, e.g. sensors. It is not used for DDC communication. Sanford

…

On 02/26/2017 08:20 AM, fm99 wrote: Hi Sanford Thank you for looking at my problem. Both 'ddcutil setvcp d0 x11' and 'ddcutil setvcp d0 x12' give me the error message "Invalid display number". Please find attached the output of the commands you have been asked for (including also the result of 'ddcutil interrogate'). The output looks fairly "normal" and "unsuspicious" to me. Being not an expert, I can only guess what might be wrong or missing. Maybe I need to load more I2C kernel modules (i2c_dev, i2c_piix4)? ddcutil environment.txt <https://github.com/rockowitz/ddcutil/files/801984/ddcutil.environment.txt> ddcutil detect --verbose --ddc --force-slave-address.txt <https://github.com/rockowitz/ddcutil/files/801986/ddcutil.detect.--verbose.--ddc.--force-slave-address.txt> ddcutil environment --verbose.txt <https://github.com/rockowitz/ddcutil/files/801987/ddcutil.environment.--verbose.txt> ddcutil interrogate.txt <https://github.com/rockowitz/ddcutil/files/801988/ddcutil.interrogate.txt> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbpMCJ47CBjqNoYsTfNVWC83bm5mdks5rgXw7gaJpZM4MMIzn>.

[fm99]

Here we go:

1. "[...] you're using an HP desktop with a Xeon processor having integrated graphics. Is that correct? Model?" => It's a HP EliteDesk 800 Mini PC (model F6X30EA#UUZ) with an i7-4785T CPU and an Integrated Graphics Controller.
2. "Is there a secondary video card in the system?" => Nope.
3. "If this happens to be a laptop, [...]" => It's not a laptop and there is no docking station.
4. "Please try the following commands and send me the output." => Output:
   ddcutil detect --verbose --trace ddc --trace i2c --stats.txt
   ddcutil getvcp 10 --verbose --trace ddc --trace i2c --stats.txt
   ddcutil getvcp 10 --bus 6 --force --verbose --trace ddc --trace i2c --stats.txt

FYI: I have just built and configured ddcutil for my Raspberry Pi. The output for the first set of commands looks similar, i.e. on the Raspi I also get the "Invalid display" and "DDC communication failed" errors:
ddcutil environment.raspi.txt
ddcutil detect --verbose --ddc --force-slave-address.raspi.txt
ddcutil environment --verbose.raspi.txt
ddcutil interrogate.raspi.txt

Thank you.

[rockowitz]

As a sanity check in monitor detection, ddcutil attempts to read the current brightness value (feature x10). I've yet to see a monitor that supports DDC but does not support this feature. Your monitor is returning, not a normal answer, but a "NULL Message" (which is a well formed response). (There is a documented way of indicating a feature is unsupported, but I have seen monitors that instead use the NULL Message for this purpose.) So DDC communication is working, but per the spec the NULL Message "tell(s) the host that the display does not have any answer to give the host." Which leads to the following: 1) Is DDC/CI communication enabled in the monitor's on-screen display. I've looked in the manual for your monitor and this appears to be a setting on the Extra menu. 2) If that doesn't solve the problem, do you have another monitor you can plug in for testing? Sanford

…

On 02/26/2017 12:50 PM, fm99 wrote: Here we go: 1. "[...] you're using an HP desktop with a Xeon processor having integrated graphics. Is that correct? Model?" => It's a HP EliteDesk 800 Mini PC (model F6X30EA#UUZ) with an i7-4785T CPU and an Integrated Graphics Controller. 2. "Is there a secondary video card in the system?" => Nope. 3. "If this happens to be a laptop, [...]" => It's not a laptop and there is no docking station. 4. "Please try the following commands and send me the output." => Output: ddcutil detect --verbose --trace ddc --trace i2c --stats.txt <https://github.com/rockowitz/ddcutil/files/802133/ddcutil.detect.--verbose.--trace.ddc.--trace.i2c.--stats.txt> ddcutil getvcp 10 --verbose --trace ddc --trace i2c --stats.txt <https://github.com/rockowitz/ddcutil/files/802134/ddcutil.getvcp.10.--verbose.--trace.ddc.--trace.i2c.--stats.txt> ddcutil getvcp 10 --bus 6 --force --verbose --trace ddc --trace i2c --stats.txt <https://github.com/rockowitz/ddcutil/files/802135/ddcutil.getvcp.10.--bus.6.--force.--verbose.--trace.ddc.--trace.i2c.--stats.txt> FYI: I have just built and configured ddcutil for my Raspberry Pi. The output for the first set of commands looks similar, i.e. on the Raspi I also get the "Invalid display" and "DDC communication failed" errors: ddcutil environment.raspi.txt <https://github.com/rockowitz/ddcutil/files/802136/ddcutil.environment.raspi.txt> ddcutil detect --verbose --ddc --force-slave-address.raspi.txt <https://github.com/rockowitz/ddcutil/files/802138/ddcutil.detect.--verbose.--ddc.--force-slave-address.raspi.txt> ddcutil environment --verbose.raspi.txt <https://github.com/rockowitz/ddcutil/files/802140/ddcutil.environment.--verbose.raspi.txt> ddcutil interrogate.raspi.txt <https://github.com/rockowitz/ddcutil/files/802141/ddcutil.interrogate.raspi.txt> Thank you. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbqrGysUU4NHmcGZXbQ7BLu3Wpmfsks5rgbtTgaJpZM4MMIzn>.

[fm99]

Hi again. You had the same thoughts as I did: In the user manual of the monitor there is an "Extra" tab mentioned on the OSD menu with an DDC-CI option for turning on/off DDC-CI support - on my monitor this option was turned off (default) :‑/ . So I have turned on DDC-CI and bingo: ddcutil does not complain anymore, i.e. I now get information for "Display 1" and the "DDC communication" error has gone.

The next problem was that switching interfaces with 'ddcutil setvcp d0 x11' (Linux PC -> Raspi) and 'ddcutil setvcp d0 x0f' (Raspi -> Linux PC) did not work: "Unrecognized VCP feature code: 0d". Finally, I have also found the solution for this remaining obstacle. The output of 'ddcutil capabilities' told me that the code for my monitor for changing input sources is 60 (and not 0d). So the working CLI commands for switching interfaces in my situation are 'ddcutil setvcp 60 x11' (Linux PC -> Raspi) and 'ddcutil setvcp 60 x0f' (Raspi -> Linux PC) - for both I have now defined handy keyboard shortcuts - mission accomplished :-))

Sanford, let me apologize for the fact that I have opened an issue here because of a wrong OSD default setting. I hope you have not spent too much time investigating my problem. I thank you very much for your efforts! You might want to consider adding a hint on your documentaton site (http://www.ddcutil.com/) for checking OSD settings before using ddcutil or reporting problems.

I owe you one!

[rockowitz]

I'm glad that we've resolved the problem. and I now can cite an example of someone using ddcutil to switch a monitor between a PC and a Pi. The effort was worth it, as it highlights the need to add documentation about this setting and possibly enhance the error messages. The problem is that it's just a hint. I turned off DDC/CI on 2 different monitors here, and neither failed in quite the same way as yours. Much of the challenge in writing ddcutil is that there's so much variation in how monitors interpret, or misinterpret, the specs. One problem is that the monitor's response to the capabilities command does not always accurately describe the features that the monitor supports. It should be taken as guidance, not gospel, and ddcutil does not rely on it. I said in an earlier post that you have to issue the setvcp 60 command from the computer to which the monitor is currently connected. Some tests suggest that depending on the monitor this may not always be required. Let me know if you can switch in both directions from the PC or the Pi. Lastly, now that things are working, please run the "ddcutil interrogate" command on both the PC and the Pi. The output will be much longer than before, and will help me understand the variability among monitors and systems. Regards, Sanford

…

On 02/26/2017 03:05 PM, fm99 wrote: Hi again. You had the same thoughts as I did: In the user manual of the monitor there is an "Extra" tab mentioned on the OSD menu with an DDC-CI option for turning on/off DDC-CI support - on my monitor this option was turn off (default) :‑/ . So I have turned on DDC-CI and bingo: ddcutil does not complain anymore, i.e. I now get information for "Display 1" and the "DDC communication" error has gone. The next problem was that switching interfaces with 'ddcutil setvcp d0 x11' (Linux PC -> Raspi) and 'ddcutil setvcp d0 x0f' (Raspi -> Linux PC) did not work: "Unrecognized VCP feature code: 0d". Finally, I have also found the solution for this remaining obstacle. The output of 'ddcutil capabilities' told me that the code for my monitor for changing input sources is 60 (and not 0d). So the working CLI commands for switching interfaces in my situation are 'ddcutil setvcp 60 x11' (Linux PC -> Raspi) and 'ddcutil setvcp 60 x0f' (Raspi -> Linux PC) - for both I have now defined handy keyboard shortcuts - mission accomplished :-)) Stanford, let me apologize for the fact that I have opened an issue here because of a wrong OSD default setting. I hope you have not spent too much time investigating my problem. I thank you very much for your efforts! You might want to consider adding a hint on you documentaton site (http://www.ddcutil.com/) for checking OSD settings before using ddcutil or reporting problems. I owe you one! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbvWDVKY8bqeUJeRPpeTJlTFnMwjyks5rgdrtgaJpZM4MMIzn>.

[fm99]

I'm glad you say that the effort was worth it.

1. "Let me know if you can switch in both directions from the PC or the Pi." => Yes, it's working in both directions: On the Linux PC I enter 'ddcutil setvcp 60 x11' which switches to HDMI-1 where the Raspi is attached, and on the Raspi the command 'ddcutil setvcp 60 x0f' switches to DisplayPort-1 with my Linux PC attached. Apart from being very convenient, switching via ddcutil is much faster (<< 1s) than pressing the respective monitor button (~ 5s).

2. Please find attached the output of 'ddcutil interrogate' from both machines:
   ddcutil interrogate.LinuxPC.txt
   ddcutil interrogate.Raspi.txt

Let me thank you again for your help and for the many interesting explanations that you have provided. Please keep up your excellent work - ddcutil is a very useful and cool tool!

All the best from Switzerland & kind regards,
Fabian M.

[rockowitz]

On 02/26/2017 04:33 PM, fm99 wrote: I'm glad you say that the effort was worth it. 1. "Let me know if you can switch in both directions from the PC or the Pi." => Yes, it's working in both directions: On the Linux PC I enter 'ddcutil setvcp 60 x11' which switches to HDMI-1 where the Raspi is attached, and on the Raspi the command 'ddcutil setvcp 60 x0f' switches to DisplayPort-1 with my Linux PC attached. Apart from being very convenient, switching via ddcutil is much faster (<< 1s) than pressing the respective monitor button (~ 5s).

That's as expected. What I'm wondering is whether, just from the Linux PC, you can issue the command "ddcutil setvcp 60 x11" to switch to the Pi and then, again from the Linux PC, issue the command "ddcutil setvcp 60 x0f" to switch back. In principle the latter command should fail, but depending on how the monitor implements DDC it just might work.

1. 2. Please find attached the output of 'ddcutil interrogate' from both machines: ddcutil interrogate.LinuxPC.txt <https://github.com/rockowitz/ddcutil/files/802310/ddcutil.interrogate.LinuxPC.txt> ddcutil interrogate.Raspi.txt <https://github.com/rockowitz/ddcutil/files/802312/ddcutil.interrogate.Raspi.txt>

Interesting that feature x60 cannot be read, but only written. Per the spec it should be RW.

1. Let me thank you again for your help and for the many interesting explanations that you have provided. Please keep up your excellent work - ddcutil is a very useful and cool tool!

Thanks for the kind words. ddcutil began as a small project to fill a personal need and has become somewhat of a monster. It's one thing to write something that works for yourself, quite another to put it out in the world and have it work everywhere. Sanford All the best from Switzerland & kind regards,

…

Fabian M. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbkVCQiF35AmcwACbWu9XgtKe-wnZks5rge-ugaJpZM4MMIzn>.

[fm99]

"What I'm wondering is whether, just from the Linux PC, you can issue the command "ddcutil setvcp 60 x11" to switch to the Pi and then, again from the Linux PC, issue the command "ddcutil setvcp 60 x0f" to switch back." => This is working as well. While the monitor was showing the screen of my Raspi I've ssh'ed from my Android smartphone to my Linux PC and launched 'ddcutil setvcp 60 x0f' - the result was that my monitor switched back to the Linux PC - hope this helps.

[rockowitz]

On 02/26/2017 05:15 PM, fm99 wrote: "What I'm wondering is whether, just from the Linux PC, you can issue the command "ddcutil setvcp 60 x11" to switch to the Pi and then, again from the Linux PC, issue the command "ddcutil setvcp 60 x0f" to switch back." => This is working as well. While the monitor was showing the screen of my Raspi I've ssh'ed from my Android smartphone to my Linux PC and launched 'ddcutil setvcp 60 x0f' - the result was that my monitor switched back to the Linux PC - hope this helps.

Most interesting. Looking at the output of interrogate for the Pi, it occurs to me that if you're memory constrained on that system you might want to build ddcutil without support for USB connected monitors (configure option --disable-usb). It would reduce the executable size by around 400K.

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsblhZU2lmq2eFrJg9cArE_ozjsNeYks5rgfmKgaJpZM4MMIzn>.

[fm99]

Thanks for the advice. I'm just re-compiling ddcutil with the option --disable-usb ;-)

Update:

# before # ./configure --disable-usb && make && make install :
-rwxr-xr-x 1 1182084 17:03:01 2017-02-26 /usr/local/bin/ddcutil

# after ## ./configure --disable-usb && make && make install :
-rwxr-xr-x 1 881852 23:56:25 2017-02-26 /usr/local/bin/ddcutil

# delta (with both executables unstripped): 300232 bytes