DDC communication failed for Display Port attached monitor about ddcutil

[TeaObvious]

As i think more Data is better i also want to contribute some dumps. I have the Samsung Odyssey G9 (LC49G95T) and i can also get DDC running with HDMI but not DisplayPort. The Problem is i can only provide mixed Data with the HDMI being connected to my Intel Notebook and the DisplayPort being connected to my Vega running with the amdgpu driver.

The files are labeled Intel-interrogation and Intel-env for the HDMI on my Notebook and AMD-interrogation and AMD-env for DisplayPort on my VEGA.

Intel-env.txt
Intel-interrogate.txt
AMD-interrogate.txt
AMD-env.txt

Output from "i2cdetect 4" on the AMD System: i2cdetect.txt

[rockowitz]

Thank you for sending the interrogate output. I have added an entry for the RDT232WLM to documentation page Notes on Specific Monitors <http://www.ddcutil.com/monitor_notes> Sanford

…

On 3/6/19 11:08 AM, helionmelion wrote: You ran the interrogate command as user ia, not root, so lacked privileges to access the /dev/i2c devices. Please run it as root. Here we go: ROOTinterrogateDVI.txt <https://github.com/rockowitz/ddcutil/files/2937155/ROOTinterrogateDVI.txt> ROOTinterrogateHDMI.txt <https://github.com/rockowitz/ddcutil/files/2937156/ROOTinterrogateHDMI.txt> ROOTinterrogateHDMI+DVI.txt <https://github.com/rockowitz/ddcutil/files/2937157/ROOTinterrogateHDMI%2BDVI.txt> Alternatively, you can create group i2c, assign the /dev/i2c devices to that group, grant RW access to the dev/i2c devices to members of that group, and assign user ia to the group. See the comments at the end of the (current) interrogate output, or page Device Permissions I'll study about this and learn later Best Regards. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbrkK57c01IzRMl-Br5Z3L45BMzLFks5vT-f0gaJpZM4M1CnT>.

[razamatan]

i contacted samsung chat support (i know), and they told me that the monitor currently doesn't support ddc/ci over dp. looking at the ddc protocol (wikipedia entry, i know.. :), it seems that ddc/ci is optional over dp:

Like modern analog VGA connectors, the DVI and DP connectors include pins for the display data channel (DDC), but DP supports DDC within its optional Dual-Mode DP (DP++) feature in DVI/HDMI mode only.

[rockowitz]

Have you tried swapping the monitors? Though the monitors have the same model string, the EDIDs show that they are slightly different. Does the problem stay with the monitor, or with the DisplayPort connection? Is DDC/CI enabled in the OSD? Please run the command "ddcutil environment --verbose" and send the output as an attachment. From ddcutil's perspective, there's no difference between a DisplayPort and non-DisplayPort connection. That the video driver emulates the I2C bus over the DisplayPort AUX channel should be transparent. However, given the newness of the amdgpu driver I wouldn't be surprised if there are issues. I have a RX280 card in a test system. I'll make a point of testing it with amdgpu/DisplayPort. Sanford

…

On 04/05/2017 10:25 PM, Jan wrote: Hello I'm using 2 monitors LG 24EB23. Both attached to an Radeon R9 290 using the amdgpu driver on an Arch linux with the latest kernel (4.10.8) I can control the monitor attached via DVI with ddcutil. But not the one attached via DP |# ddcutil detect --verbose Output level: Verbose Reporting DDC data errors: false Trace groups active: none Force I2C slave address: false Display 1 I2C bus: /dev/i2c-5 Supports DDC: true I2C address 0x30 (EDID block#) present: true I2C address 0x37 (DDC) present: true I2C address 0x50 (EDID) present: true /sys/bus/i2c/devices/i2c-5/name: AMDGPU i2c bit bus 0x95 EDID synopsis: Mfg id: GSM Model: 24EB23 Serial number: (disclosed) Manufacture year: 2014 EDID version: 1.3 Product code: 0x59b4 (22964) Extra descriptor: Unspecified Video input definition: 0x80 - Digital Input White x,y: 0.312, 0.329 Red x,y: 0.652, 0.335 Green x,y: 0.304, 0.633 Blue x,y: 0.152, 0.065 Extension blocks: 0 EDID hex dump: +0 +4 +8 +c 0 4 8 c +0000 00 ff ff ff ff ff ff 00 1e 6d b4 59 b4 9b 02 00 .........m.Y.... +0010 09 18 01 03 80 34 21 78 ea 3c 31 a7 55 4d a2 27 .....4!x.<1.UM.' +0020 10 50 54 a5 4b 00 71 4f 81 00 81 80 81 8f 95 00 .PT.K.qO........ +0030 a9 40 b3 00 d1 c0 28 3c 80 a0 70 b0 23 40 30 20 .@....***@***.*** +0040 36 00 08 4a 21 00 00 1a 00 00 00 fd 00 38 4b 1e 6..J!........8K. +0050 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 32 S... .....2 +0060 34 45 42 32 33 0a 20 20 20 20 20 20 00 00 00 ff 4EB23. .... +0070 00 0a 20 20 20 20 20 20 20 20 20 20 20 20 01 d4 .. .. VCP version: 2.1 Controller mfg: Mstar Firmware version: 1.1 Invalid display I2C bus: /dev/i2c-8 Supports DDC: true I2C address 0x30 (EDID block#) present: false I2C address 0x37 (DDC) present: true I2C address 0x50 (EDID) present: true /sys/bus/i2c/devices/i2c-8/name: card0-DP-1 EDID synopsis: Mfg id: GSM Model: 24EB23 Serial number: Manufacture year: 2013 EDID version: 1.4 Product code: 0x59b5 (22965) Extra descriptor: Unspecified Video input definition: 0xa5 - Digital Input(DisplayPort) White x,y: 0.312, 0.329 Red x,y: 0.652, 0.335 Green x,y: 0.304, 0.633 Blue x,y: 0.152, 0.065 Extension blocks: 1 EDID hex dump: +0 +4 +8 +c 0 4 8 c +0000 00 ff ff ff ff ff ff 00 1e 6d b5 59 01 01 01 01 .........m.Y.... +0010 01 17 01 04 a5 34 21 78 fa 3c 31 a7 55 4d a2 27 .....4!x.<1.UM.' +0020 10 50 54 21 08 00 71 40 81 c0 81 00 81 80 95 00 .***@***.*** +0030 a9 40 b3 00 d1 c0 28 3c 80 a0 70 b0 23 40 30 20 .@....***@***.*** +0040 36 00 08 4a 21 00 00 1a 00 00 00 fd 00 38 3d 1e 6..J!........8=. +0050 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 32 S... .....2 +0060 34 45 42 32 33 0a 20 20 20 20 20 20 00 00 00 ff 4EB23. .... +0070 00 0a 20 20 20 20 20 20 20 20 20 20 20 20 01 d4 .. .. DDC communication failed Is DDC/CI enabled in the monitor's on-screen display? | (I've stripped the serial number from the first hex dump, the second was already empty) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbj_60DGMbbcEqpt5SDLjpxdTs2yhks5rtE0MgaJpZM4M1CnT>.

[jnhmn]

I've not directly swapped the monitors due to a short DVI cable, but the problem stays with the DP connection (same cable, never had problems with it)
If I attach the previous DVI-Monitor via DP, its manufacture year and EDID-version changes (2014->2013; 1.3->1.4) (I have rebooted the system to verify it)

I have no idea, how to enable DDC/CI in the OSD or if it can be disabled.

Also the EDID information for the DP monitor do not show up every time (see both attached files)
ddcenv.txt
ddcenv2.txt

please tell me, if I can provide further information.

Edit:
The problem also exists under Windows 8.1 with the ScreenBright tool
And the problem also exists if I attach the DP monitor to the integrated Intel i915 card (Sandy Bridge)
I begin to think that there is a problem with the monitor itself and not with the video card.

[rockowitz]

On 04/06/2017 08:10 PM, Jan wrote: I've not directly swapped the monitors due to a short DVI cable, but the problem stays with the DP connection (same cable, never had problems with it) If I attach the previous DVI-Monitor via DP, its manufacture year and EDID-version changes (2014->2013; 1.3->1.4) (I have rebooted the system to verify it I have no idea, how to enable DDC/CI in the OSD or if it can be disabled.

I've looked in the user manual for your monitor, and it doesn't appear there's any setting to control DDC/CI, which is very unusual. The manual states the monitor is DDC2B compliant. DDC2B is an older iteration in the DDC family of specs, but it probably means the monitor supports DDC/CI.

Also the EDID information for the DP monitor do not show up every time (see both attached files) ddcenv.txt <https://github.com/rockowitz/ddcutil/files/904201/ddcenv.txt> ddcenv2.txt <https://github.com/rockowitz/ddcutil/files/904202/ddcenv2.txt> please tell me, if I can provide further information.

Given the i2cdetect also reports unexpected data for the I2C device on DisplayPort, and the kind of failures observed, I'm pretty certain this is an issue of the I2C over DisplayPort Aux Channel implementation in the amdgpu driver, which is not surprising given that it's still under active development. If I can replicate the problem I'll file a bug report. Unfortunately there's not a spare DisplayPort monitor here, and it will take some rearrangement to free up one of the monitors with a DisplayPort connection for use on the test system, so that may take a few days. Sanford

…

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

[infernix]

I have a similar problem here with an secondary Acer XB270HU on DP (only has that as connectivity). Manual states DDC2B support, works great on Windows but on linux no EDID and no DDC. Primary screen (Samsung SA850, also over DP) works great, even with DDC controls for brightness etc.

When plugging in the Acer:

Aug 05 00:28:44 believe kernel: [drm:amdgpu_atombios_encoder_set_bios_scratch_regs] DFP2 connected
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0
Aug 05 00:28:44 believe kernel: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:49:DP-2] probed modes :
Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 82:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 79:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 78:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 80:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 77:"640x480" 60 25175 640 656 752 800 480 490 492 525 0x40 0xa

I2C nack doesn't seem right. ddcutil returns: Failure getting EDID for /dev/i2c-9: status code=EREMOTEIO(-121): Remote I/O error but that makes sense if the kernel isn't able to set up I2C comms properly.

i2cdetect:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

Since it works fine on Windows 10 with the GTX980, I will take a stab at booting a livecd on it and see where that gets me. I can also try the onboard i915 with it, have done neither yet.

Edit: fwiw this is with 4.12.4 and amdgpu on a HD7850

[rockowitz]

Gerben, Please run the following commands as root and send the output as an attachment. Without that output its hard for me to say much. # ddcutil environment --verbose # ls -ld /sys/class/drm/card*/card-*/i2c* (The latter command will go into the next point release of ddcutil.) Looking at the code for drm_dp_i2c_do_msg.c, the errors are coming from the I2C-over-aux related code. Normally I'd suggest trying a DVI or HDMI connection, but that isn't an option for you. The problem may be in the amdgpu driver. If using the i915 driver, be aware that there are issues with DisplayPort there as well, particularly when using a docking station. Sanford

…

On 08/04/2017 06:41 PM, Gerben Meijer wrote: I have a similar problem here with an secondary Acer XB270HU on DP (only has that as connectivity). Manual states DDC2B support, works great on Windows but on linux no EDID and no DDC. Primary screen (Samsung SA850, also over DP) works great, even with DDC controls for brightness etc. When plugging in the Acer: |Aug 05 00:28:44 believe kernel: [drm:amdgpu_atombios_encoder_set_bios_scratch_regs] DFP2 connected Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_dp_i2c_do_msg] I2C nack (result=0, size=0 Aug 05 00:28:44 believe kernel: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:49:DP-2] probed modes : Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 82:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 79:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5 Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 78:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5 Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 80:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5 Aug 05 00:28:44 believe kernel: [drm:drm_mode_debug_printmodeline] Modeline 77:"640x480" 60 25175 640 656 752 800 480 490 492 525 0x40 0xa | |I2C nack| doesn't seem right. ddcutil returns: |Failure getting EDID for /dev/i2c-9: status code=EREMOTEIO(-121): Remote I/O error| but that makes sense if the kernel isn't able to set up I2C comms properly. i2cdetect: |0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- | Since it works fine on Windows 10 with the GTX980, I will take a stab at booting a livecd on it and see where that gets me. I can also try the onboard i915 with it, have done neither yet. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbiGcKgCPMrzbs9do9BwCGFKQdNQ-ks5sU54NgaJpZM4M1CnT>.

[infernix]

So here's the same monitor on a GTX980, Ubuntu 17.04 live:

Display 1
   I2C bus:             /dev/i2c-16
   Supports DDC:        true
   EDID synopsis:
      Mfg id:           ACR
      Model:            XB270HU
      Serial number:    #ASOQgqYB8LDd
      Model year      : 2013
      EDID version:     1.4
   VCP version:         2.2

Invalid display
   I2C bus:             /dev/i2c-19
   Supports DDC:        false
   EDID synopsis:
      Mfg id:           ACR
      Model:            XB270HU
      Serial number:    #ASOQgqYB8LDd
      Model year      : 2013
      EDID version:     1.4
   DDC communication failed

Clearly there is an EDID here since it's detected when plugged in this GTX980. And I even have ddccontrol working on i2c-16, which is nvkm-0000:01:00.0-aux-0009 I2C adapter - so clearly it's an issue with the aux code. e.g. ddcutil setvcp -b 16 10 50 sets brightness levels.

ddcutil env for the box with a gtx980 - acer on i2c-16 here as only monitor

ddcutil env for the box with a HD7850 - acer on i2c-9 here as second monitor, primary on i2c-8

So it's a mystery to me why it's not working on the radeon card; perhaps because this is a G-SYNC monitor and it's doing something non-standard?

[rockowitz]

Gerben, Re the GTX980 report, the Acer monitor is connected on DP-3. What is strange is that it has 2 different I2C buses assigned, i2c-16 and i2c-19. I2C slave address x50 (EDID) works for both, so you can read the EDID on both I2C buses. However, I2C slave address x37 (DDC) is active only on I2c-16, so DDC communication works only on bus I2C-16. I have occasionally seen this double I2C bus assignment for DisplayPort monitors on my own system, and have no idea what triggers it. However, the bottom line for the GTX980 with the nouveau driver is that ddcutil works. It detects i2c-16 as valid, and i2c-19 as invalid. Re "HD7878" report, I assume you meant HD7870. However, there's no link to the report. Is this the card you're using with the amdgpu driver? Or was the original report for another card. For each relevant card/driver combination, please send the output of the following commands, run as root, as attachments: # ddcutil environment ---verbose # ddcutil detect --verbose # ls -ld /sys/class/drm/card*/card*/i2c* (Note that the last command is corrected from my prior email, which contained an extraneous "-" in the command. Sanford

…

On 08/04/2017 07:42 PM, Gerben Meijer wrote: So here's the same monitor on a GTX980, Ubuntu 17.04 live: |Display 1 I2C bus: /dev/i2c-16 Supports DDC: true EDID synopsis: Mfg id: ACR Model: XB270HU Serial number: #ASOQgqYB8LDd Model year : 2013 EDID version: 1.4 VCP version: 2.2 Invalid display I2C bus: /dev/i2c-19 Supports DDC: false EDID synopsis: Mfg id: ACR Model: XB270HU Serial number: #ASOQgqYB8LDd Model year : 2013 EDID version: 1.4 DDC communication failed | Clearly there is an EDID here since it's detected when plugged in this GTX980. And I even have ddccontrol working on i2c-16, which is |nvkm-0000:01:00.0-aux-0009 I2C adapter| - so clearly it's an issue with the aux code. e.g. |ddcutil setvcp -b 16 10 50| sets brightness levels. ddcutil env for the box with a gtx980 <https://pastebin.com/xdTrCc6u> - acer on i2c-16 here as only monitor ddcutil env for the box with a HD7878 - acer on i2c-9 here as second monitor, primary on i2c-8 So it's a mystery to me why it's not working on the radeon card; perhaps because this is a G-SYNC monitor and it's doing something non-standard? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbldfQYzAw_HpA0bZMMdwQUKbkkX5ks5sU6yAgaJpZM4M1CnT>.

[infernix]

I assume you are reading the comments over email since I fixed the link shortly after commenting; in any case, attached the data through Github this time. I included an interrogate as well.

hd7850-card-i2c.txt
hd7850-detect.txt
hd7850-env.txt
hd7850-interrogate.txt

gtx980-interrogate.txt
gtx980-find-i2c.txt
gtx980-env.txt
gtx980-detect.txt

Note that these are 2 different machines with the same CPU model; the HD7850 machine is the dual monitor setup with Debian 9 and the GTX980 is windows box where I just use a Ubuntu 17.04 live boot.

I tested this also with just the Acer screen attached and with different DP cables but none of that had any effect. I am yet to try connecting the Acer to the onboard Intel DP.

Also, on the gtx980 with the Ubuntu live cd, there is no /sys/class/drm/card*/card*/i2c*; it looks almost as if all i2c devices are under the nouveau driver. I've attached a find /sys|grep i2c instead though can't say how useful that is; this may or may not be a kernel issue.

[rockowitz]

Gerben, This pretty clearly is an amdgpu driver issue. Your HD7850 is a GCN 1.0 card, and support for these cards by the amdgpu driver is marginal. The logs show errors in function drm_dp_i2c_do_msg in drm driver file drm_do_helper.c, reflecting lower level failures. FWIW, I took the time to refresh my testbed system that has a R9 280X (Radeon 7970), also GCN 1.0, with amdgpu and kernel 4.10, and it does work. Is there some reason you're using the amdgpu driver? What happens if you use the stable radeon driver? Additional comment interspersed. Sanford

On 08/05/2017 12:19 PM, Gerben Meijer wrote: I assume you are reading the comments over email since I fixed the link shortly after commenting; in any case, attached the data through Github this time. I included an interrogate as well. hd7850-card-i2c.txt <https://github.com/rockowitz/ddcutil/files/1202486/hd7850-card-i2c.txt> hd7850-detect.txt <https://github.com/rockowitz/ddcutil/files/1202487/hd7850-detect.txt> hd7850-env.txt <https://github.com/rockowitz/ddcutil/files/1202488/hd7850-env.txt> hd7850-interrogate.txt <https://github.com/rockowitz/ddcutil/files/1202489/hd7850-interrogate.txt> gtx980-interrogate.txt <https://github.com/rockowitz/ddcutil/files/1202511/gtx980-interrogate.txt> gtx980-find-i2c.txt <https://github.com/rockowitz/ddcutil/files/1202510/gtx980-find-i2c.txt> gtx980-env.txt <https://github.com/rockowitz/ddcutil/files/1202512/gtx980-env.txt> gtx980-detect.txt <https://github.com/rockowitz/ddcutil/files/1202509/gtx980-detect.txt> Note that these are 2 different machines with the same CPU model; the HD7850 machine is the dual monitor setup with Debian 9 and the GTX980 is windows box where I just use a Ubuntu 17.04 live boot. I tested this also with just the Acer screen attached and with different DP cables but none of that had any effect. I am yet to try connecting the Acer to the onboard Intel DP. Also, on the gtx980 with the Ubuntu live cd, there is no /sys/class/drm/card*/card*/i2c*; it looks almost as if all i2c devices are under the nouveau driver. I've attached a find /sys|grep i2c instead though can't say how useful that is; this may or may not be a kernel issue.

This is as expected. The nouveau and nvidia drivers to not create i2c nodes under /sys/class/card*/card*.

…

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

[infernix]

No particular reason for amdgpu, but the radeon driver yields the exact same thing. I've attached a new set of files with radeon driver; in this set you'll see that I turned on drm debugging, then unplugged and inserted the Acer. Look for 'I2C nack'.

hd7850-card-i2c-radeon.txt
hd7850-interrogate-radeon.txt
hd7850-env-radeon.txt
hd7850-detect-radeon.txt

So it's pretty obviously an issue with both radeon and amdgpu failing to properly init the monitors I2C. I will try the screen on the Intel iGPU next.

Since it's clearly a kernel issue, do you know the best place to address this further? dri-users seems to be a dead list.

Thanks!

[rockowitz]

Gerben, Looks like the XB270HU does something the drivers don't expect. Only a couple (feeble) suggestions: - verify that DDC/CI is enabled in the OSD - Since you have a Windows system, try installing softMCCS from EnTech. They make I2C related chips, and softMCCS is their utility for testing I2C communication. It has excellent diagnostics. As for mailing lists, I haven't great suggestions. Since the problem does occur on radeon, you might try posting there. Finally, there's no need to be sending interrogate reports for this problem. Essentially, interrogate just wraps up detect --verbose, environment --verbose, and probe --verbose. probe examines monitor VCP features, which is meaningless if there's no DDC connectivity. Regards, Sanford

…

On 08/07/2017 07:09 AM, Gerben Meijer wrote: No particular reason for amdgpu, but the radeon driver yields the exact same thing. I've attached a new set of files with radeon driver; in this set you'll see that I turned on drm debugging, then unplugged and inserted the Acer. Look for 'I2C nack'. hd7850-card-i2c-radeon.txt <https://github.com/rockowitz/ddcutil/files/1204617/hd7850-card-i2c-radeon.txt> hd7850-interrogate-radeon.txt <https://github.com/rockowitz/ddcutil/files/1204616/hd7850-interrogate-radeon.txt> hd7850-env-radeon.txt <https://github.com/rockowitz/ddcutil/files/1204615/hd7850-env-radeon.txt> hd7850-detect-radeon.txt <https://github.com/rockowitz/ddcutil/files/1204618/hd7850-detect-radeon.txt> So it's pretty obviously an issue with both radeon and amdgpu failing to properly init the monitors I2C. I will try the screen on the Intel iGPU next. Since it's clearly a kernel issue, do you know the best place to address this further? dri-users seems to be a dead list. Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbu1e5k-jadeUuMfnkIBhYH2MhVqoks5sVvBkgaJpZM4M1CnT>.

[infernix]

The monitor does DDC/CI - it's enabled and cannot be turned off in the OSD. I've also attached it to intel iGPU, same problem (see interrogate). Also attached SoftMMCS report and log.

intel-card-i2c.txt
intel-interrogate.txt
softMCCS.txt
ACR0408 softMCCS test report.txt

Since it happens with both Intel and Radeon/AMDGPU I guess I can try to work with intel-gfx team; if you have any further suggestions I'm all ears. Thanks :)

[rockowitz]

No additional suggestions, I'm afraid. Do keep me posted. Sanford

…

On 08/07/2017 08:30 AM, Gerben Meijer wrote: The monitor does DDC/CI - it's enabled and cannot be turned off in the OSD. I've also attached it to intel iGPU, same problem (see interrogate). Also attached SoftMMCS report and log. intel-card-i2c.txt <https://github.com/rockowitz/ddcutil/files/1204756/intel-card-i2c.txt> intel-interrogate.txt <https://github.com/rockowitz/ddcutil/files/1204755/intel-interrogate.txt> softMCCS.txt <https://github.com/rockowitz/ddcutil/files/1204761/softMCCS.txt> ACR0408 softMCCS test report.txt <https://github.com/rockowitz/ddcutil/files/1204760/ACR0408.softMCCS.test.report.txt> Since it happens with both Intel and Radeon/AMDGPU I guess I can try to work with intel-gfx team; if you have any further suggestions I'm all ears. Thanks :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsblDmzLgbeD3ZXVUTkWdaa2jDK8hqks5sVwNTgaJpZM4M1CnT>.

[t-animal]

Any news on this? I'm experiencing similar problems.

[infernix]

I've gotten nowhere. Made a bugzilla bug for the intel-gfx team here: https://bugs.freedesktop.org/show_bug.cgi?id=102069 - I suggest to add to that thread if you get the bug on intel GPUs but not amd/nvidia gpus.

[rockowitz]

What is your hardware configuration? I2C-Over-Aux is an acknowledged problem area with the i915 driver (https://bugs.freedesktop.org/show_bug.cgi?id=100954), and other drivers also seem to have issues. If you have ddcutil installed, please run "ddcutil env -v" and "ddcutil det -v" and send the output as attachments. If you have i2c-tools installed, you can also run i2cdetect to see if slave addresses x50 and x37 are detected for any I2C device. Sanford

…

On 03/01/2018 08:41 AM, t-animal wrote: Any news on this? I'm experiencing similar problems. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbjfqzrTj0H2yDPG8XVxKUyYxzhpuks5tZ_qRgaJpZM4M1CnT>.

[t-animal]

Yes, I'm using the i915 driver. However by now I've managed to get it to work, by using a display port to DVI adapter cable. I'm trying to switch inputs and the associated command does not support switching to DP input. This leads me to the suspicion that maybe the monitor itself is part of the problem. Still investigating.

[rockowitz]

Are you (t-animal) and Gerben Meijer one and the same, or is it just coincidence that there are multiple postings on this thread today? Do you know if the monitor supports VCP feature x60 (Input Source)?   One thing I've observed with feature x60 is that the observed values do not necessarily conform the the specs.   If you can, manually set the monitor to the desired input and use "ddcutil getvcp 60" to see what the actual value is. Sanford

…

On 03/01/2018 10:23 AM, t-animal wrote: Yes, I'm using the i915 driver. However by now I've managed to get it to work, by using a display port to DVI adapter cable. I'm trying to switch inputs and the associated command does not support switching to DP input. This leads me to the suspicion that maybe the monitor itself is part of the problem. Still investigating. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbq0Fw_hGVJSeN2rhWjIBZVhsomGsks5taBJzgaJpZM4M1CnT>.

[t-animal]

Nope, I'm not Gerben Meijer. Yes, it does support x60. That is exactly the feature I'm trying to use. However while the monitor has a D-SUB (VGA), DP and DVI Input ddutil lists these values when probing:

   Feature: 60 (Input Source)
      Values:
         01: VGA-1
         03: DVI-1
         04: DVI-2

None of these values support switching to the DP input and funnily the monitor doesn't even have a secondary DVI input. So I'm guessing the firmware is screwed up or something...

[rockowitz]

Gerben, I've taken a look at the interrogate logs you posted.  It certainly does seem to isolate the problem to the i915 driver. Note that there are acknowledged issues with the i915 DP i2c-over-aux implementation - see the later comments on https://bugs.freedesktop.org/show_bug.cgi?id=100954. There's a difference in the amdgpu vs nouveau logs that I find puzzling.  When probing for features with the amdgpu driver, unsupported features are cleanly reported - i.e. the unsupported feature bit is set in a proper response packet.  This is as per the DDC spec.  With the nouveau driver, on the other hand, reading unsupported features fails because of retries exceeded.   The only interpretation I can come up with (and it's vague handwaving) is that it takes longer for the monitor to respond to a request for an unsupported feature, and that the amdgpu driver is more forgiving. Sanford

…

On 03/01/2018 09:47 AM, Gerben Meijer wrote: I've gotten nowhere. Made a bugzilla bug for the intel-gfx team here: https://bugs.freedesktop.org/show_bug.cgi?id=102069 - I suggest to add to that thread if you get the bug on intel GPUs but not amd/nvidia gpus. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbtZXOoKGoaXtLurzFgwdWuBBHnnVks5taAnkgaJpZM4M1CnT>.

[helionmelion]

Hello, I am using a radeon gpu and a DDC CI capable monitor (mitsubishi RDT232WLM).
Unfortunately the test result is also "Invalid display" and "DDC communication failed".
Posting the output of ddcutil environment --verbose and ddcutil detect --verbose:
detect.txt
environment.txt

[rockowitz]

I assume you're the same person as user magnesium who posted a similar query in AUR (https://aur.archlinux.org/packages/ddcutil/). You're running a version of ddcutil (0.8.6) that's over a year old.  The current version, 0.9.5, is in AUR.  If you're actually using ddcutil, I suggest you upgrade.  That said, I don't believe your problem is related to the ddcutil version. Your monitor is found on bus /dev/i2c-1.    Slave address x37 (DDC/CI) is not responding.  Among the several ways that the environment command probes for displays, it calls external program i2cdetect (i2cdetect -y 1), and that program too shows no response. I'm afraid I don't have any very good suggestions for you.  The post on AUR indicates you've checked the DDC enabled setting in the OSD.  You might try running as root, though I don't see why that would make a difference.  You might also try using a different connector, though the specifications I've found, as well as the environment output, indicate there's no DisplayPort connector on this monitor and DisplayPort is the one connector that tends to show variation. Sanford

On 3/4/19 10:39 AM, helionmelion wrote: Hello, I am using a radeon gpu and a DDC CI capable monitor (mitsubishi RDT232WLM). Unfortunately the test result is also "Invalid display" and "DDC communication failed". Posting the output of ddcutil environment --verbose

<output deleted>

[helionmelion]

I assume you're the same person as user magnesium who posted a similar
query in AUR (https://aur.archlinux.org/packages/ddcutil/).

Yes, I am the same person.

You're running a version of ddcutil (0.8.6) that's over a year old. The
current version, 0.9.5, is in AUR. If you're actually using ddcutil, I
suggest you upgrade.

Upgrade done.

You might also try using a different connector, though the
specifications I've found, as well as the environment output, indicate
there's no DisplayPort connector on this monitor and DisplayPort is the
one connector that tends to show variation.

This monitor and video card does not have Displayport, but tried switching conectors from HDMI to old DVI and... it worked!
Now, the monitor is detected!! Success!!!

env2.txt
detect2.txt

Seems the problems is with HDMI connector!
@rockowitz Thank you very much!!! Live long to ddcutil.

[rockowitz]

I'm glad to hear that switching from the HDMI to DVI connector on the monitor resolved the problem, though I must admit that the suggestion was a long shot.  In terms of circuitry, DVI and HDMI are essentially the same.  DVI connections are often reported as HDMI, and vice-versa.  What connectors were you using on the video card in each case? Can I ask you run the interrogate command and send the output? I'll add a description of your monitors to www.ddcutil.com/monitor_notes. Sanford

…

On 3/4/19 5:22 PM, helionmelion wrote: I assume you're the same person as user magnesium who posted a similar query in AUR (https://aur.archlinux.org/packages/ddcutil/). Yes, I am the same person. You're running a version of ddcutil (0.8.6) that's over a year old. The current version, 0.9.5, is in AUR. If you're actually using ddcutil, I suggest you upgrade. Upgrade done. You might also try using a different connector, though the specifications I've found, as well as the environment output, indicate there's no DisplayPort connector on this monitor and DisplayPort is the one connector that tends to show variation. This monitor and video card does not have Displayport, but tried switching conectors from HDMI to old DVI and... it worked! *Now, the monitor is detected!! Success!!!* env2.txt <https://github.com/rockowitz/ddcutil/files/2928418/env2.txt> detect2.txt <https://github.com/rockowitz/ddcutil/files/2928419/detect2.txt> Seems the problems is with HDMI connector! @rockowitz <https://github.com/rockowitz> Thank you very much!!! Live long to ddcutil. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbvHoxgdhQOlAKZjxHlKgZ-66OdRaks5vTZzAgaJpZM4M1CnT>.

[helionmelion]

In terms of circuitry, DVI and HDMI are essentially
the same.

I didn't know that.

What connectors were you using on the video card in each case?

I'm using the same connectors on monitor and video card side. HDMI with HDMI, and DVI with DVI. No adapters of any kind.

Connecting both HDMI and DVI (but using DVI of course), the funcion loadvcp (profile) does not work.
[ia@sun ~] % sudo ddcutil loadvcp ddcnight [1][8:59:34]
Monitor not connected: RDT232WLM - 0Z247468AJ

So I have to disconnect HDMI permanently to use loadvcp.

Can I ask you run the interrogate command and send the output?

Of course.
interrogateHDMIandDVI.txt
interrogateDVIonly.txt
interrogateHDMIonly.txt

Hoping this could help others. Thank you for your attention.

(Addendum)
For the first time, I noted that OSD configurations for each connection is saved in a separate buffer, inside the monitor. Setting brightness and color for DVI does not interfere with HDMI saved config and vice versa. Perhaps could this be a clue.

[rockowitz]

You ran the interrogate command as user ia, not root, so lacked privileges to access the /dev/i2c devices.  Please run it as root.  Alternatively, you can create group i2c, assign the /dev/i2c devices to that group, grant RW access to the dev/i2c devices to members of that group, and assign user ia to the group.  See the comments at the end of the (current) interrogate output, or page Device Permissions <http://www.ddcutil/i2c_permissions> Sanford

…

On 3/5/19 7:14 AM, helionmelion wrote: In terms of circuitry, DVI and HDMI are essentially the same. I didn't know that. What connectors were you using on the video card in each case? I'm using the same connectors on monitor and video card side. HDMI with HDMI, and DVI with DVI. No adapters of any kind. Connecting both HDMI and DVI (but using DVI of course), the funcion loadvcp (profile) does not work. ***@***.*** ~] % sudo ddcutil loadvcp ddcnight [1][8:59:34]| |Monitor not connected: RDT232WLM - 0Z247468AJ | So I have to disconnect HDMI permanently to use loadvcp. Can I ask you run the interrogate command and send the output? Of course. interrogateHDMIandDVI.txt <https://github.com/rockowitz/ddcutil/files/2930822/interrogateHDMIandDVI.txt> interrogateDVIonly.txt <https://github.com/rockowitz/ddcutil/files/2930823/interrogateDVIonly.txt> Hoping this could help others. Thank you for your attention. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANhsbjehyLiSHIg_PAcsa1_OlWrQY6N0ks5vTl-vgaJpZM4M1CnT>.

[helionmelion]

You ran the interrogate command as user ia, not root, so lacked
privileges to access the /dev/i2c devices. Please run it as root.

Here we go:
ROOTinterrogateDVI.txt
ROOTinterrogateHDMI.txt
ROOTinterrogateHDMI+DVI.txt

Alternatively, you can create group i2c, assign the /dev/i2c devices to
that group, grant RW access to the dev/i2c devices to members of that
group, and assign user ia to the group. See the comments at the end of
the (current) interrogate output, or page Device Permissions

I'll study about this and learn later
Best Regards.

[etylermoss]

I have a similar issue as this, except for I am using (having trouble with) HDMI. My monitor is an ASUS VG248QE, DDC enabled in the OSD. It is also connected to a Windows 10 machine through an Nvidia GTX 780 GPU using Display Port, and DDC works there. However on Linux I am using Integrated AMD Vega Graphics with the amdgpu driver. More specifically the Ryzen 2400G, which uses Vega 11 graphics. Motherboard is a MSI Gaming Carbon Pro.

I'm using 0.9.5-1 of ddcutil on Arch Linux with the 5.0.5 Linux Kernel.

$> ddcutil detect --verbose

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

Invalid display
   I2C bus:             /dev/i2c-4
      I2C address 0x50 (EDID) present: true 
      Is eDP device:                   false
      /sys/bus/i2c/devices/i2c-4/name: AMDGPU DM i2c hw bus 0
   EDID synopsis:
      Mfg id:           ACI
      Model:            VG248
      Serial number:    FALMQS138687
      Manufacture year: 2015
      EDID version:     1.3
      Product code:     9381
      Extra descriptor: Unspecified
      Video input definition: 0x80 - Digital Input
      Supported features:
         DPMS standby
         DPMS suspend
         DPMS active-off
         Digital display type: RGB 4:4:4
         Standard sRGB color space: False
      White x,y:        0.313, 0.329
      Red   x,y:        0.650, 0.329
      Green x,y:        0.331, 0.622
      Blue  x,y:        0.151, 0.053
      Extension blocks: 1
   EDID source: 
   EDID hex dump:
              +0          +4          +8          +c            0   4   8   c   
      +0000   00 ff ff ff ff ff ff 00 04 69 a5 24 01 01 01 01   .........i.$....
      +0010   2c 19 01 03 80 35 1e 78 ea 9d e5 a6 54 54 9f 26   ,....5.x....TT.&
      +0020   0d 50 54 b7 ef 00 71 4f 81 80 81 40 81 c0 81 00   .PT...qO...@....
      +0030   95 00 b3 00 01 01 02 3a 80 18 71 38 2d 40 58 2c   .......:..q8-@X,
      +0040   45 00 13 2b 21 00 00 1e 00 00 00 fd 00 32 4c 1e   E..+!........2L.
      +0050   53 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 56   S...      .....V
      +0060   47 32 34 38 0a 20 20 20 20 20 20 20 00 00 00 ff   G248.       ....
      +0070   00 46 41 4c 4d 51 53 31 33 38 36 38 37 0a 01 ad   .FALMQS138687...
   DDC communication failed
   Is DDC/CI enabled in the monitor's on-screen display?

[rockowitz]

Please run "sudo ddcutil env --verbose" or "sudo ddcutil interrogate" and send the output as an attachment. Sanford

…

On 5/10/19 8:22 PM, Eden Tyler-Moss wrote: I have a similar issue as this, except for I am using HDMI to HDMI from the get go. My monitor is an ASUS VG248QE, DDC enabled in the OSD. It is also connected to a Windows 10 machine through an Nvidia GTX 780 GPU using Display Port, and DDC works there. However on Linux I am using Integrated AMD Vega Graphics with the |amdgpu| driver. More specifically the Ryzen 2400G, which uses Vega 11 graphics. Motherboard is a MSI Gaming Carbon Pro. I'm using 0.9.5-1 of ddcutil on Arch Linux with the 5.0.5 Linux Kernel. |$> ddcutil detect --verbose Output level: Verbose Reporting DDC data errors: false Trace groups active: none Traced functions: none Traced files: none Force I2C slave address: false User defined features: disabled Invalid display I2C bus: /dev/i2c-4 I2C address 0x50 (EDID) present: true Is eDP device: false /sys/bus/i2c/devices/i2c-4/name: AMDGPU DM i2c hw bus 0 EDID synopsis: Mfg id: ACI Model: VG248 Serial number: FALMQS138687 Manufacture year: 2015 EDID version: 1.3 Product code: 9381 Extra descriptor: Unspecified Video input definition: 0x80 - Digital Input Supported features: DPMS standby DPMS suspend DPMS active-off Digital display type: RGB 4:4:4 Standard sRGB color space: False White x,y: 0.313, 0.329 Red x,y: 0.650, 0.329 Green x,y: 0.331, 0.622 Blue x,y: 0.151, 0.053 Extension blocks: 1 EDID source: EDID hex dump: +0 +4 +8 +c 0 4 8 c +0000 00 ff ff ff ff ff ff 00 04 69 a5 24 01 01 01 01 .........i.$.... +0010 2c 19 01 03 80 35 1e 78 ea 9d e5 a6 54 54 9f 26 ,....5.x....TT.& +0020 0d 50 54 b7 ef 00 71 4f 81 80 81 40 81 c0 81 00 .***@***.*** +0030 95 00 b3 00 01 01 02 3a 80 18 71 38 2d 40 58 2c .......***@***.***, +0040 45 00 13 2b 21 00 00 1e 00 00 00 fd 00 32 4c 1e E..+!........2L. +0050 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 56 S... .....V +0060 47 32 34 38 0a 20 20 20 20 20 20 20 00 00 00 ff G248. .... +0070 00 46 41 4c 4d 51 53 31 33 38 36 38 37 0a 01 ad .FALMQS138687... DDC communication failed Is DDC/CI enabled in the monitor's on-screen display? | — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADMGY3XE7TT7MJ34LVRNCKDPUYGTZANCNFSM4DGUFHJQ>.

[etylermoss]

sudo ddcutil env --verbose and sudo ddcutil interrogate

[rockowitz]

Based on the description in your previous note and the output from environment/interrogate you have 2 monitors connected to the AMD Vega Graphics, the Asus VG248QE you mentioned, and also a monitor with manufacturer code DIX (not listed in either /usr/share/hwdata/pnp.ids or the official list at https://uefi.org/pnp_id_list) and model X19W. Online search suggests the manufacturer is "Advent", but I can't find any manual for it, so I can't tell if it should support DDC/CI. Additionally, there is an evga GTX 780 Ti in the system.   You describe the Windows 10 machine as having at GTX 780.  Is this a coincidence or are you running Windows in a virtual machine? That the vfio-pci driver is loaded suggests the latter. Does DDC work on initial connection before you switch to Windows and switch back, or does it always fail?  How are you switching from Windows to Linux and vice versa? I can see that attempting to read feature x10 (brightness) from the Asus receives a garbage response (all bytes 6e), and attempting to read from the X19W receives all bytes x00. Please install command i2cdetect (usually in package i2c-tools). Since your monitors are on /dev/i2c-4 and /dev/i2c-6, issue the commands "i2cdetect 4" and "i2cdetect 6".   You should see slave address x50 listed as active (EDID).  Is slave address x37 (DDC) also active? Sanford

…

On 5/11/19 7:17 AM, Eden Tyler-Moss wrote: sudo ddcutil env --verbose <https://pastebin.com/0mDD9VvT> and sudo ddcutil interrogate <https://pastebin.com/Hep88ZSU> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADMGY3VTN5MWMSWP7ZZBYVTPU2TMDANCNFSM4DGUFHJQ>.

[etylermoss]

Yeah I also have a second monitor attached (only) to the Vega GPU, it's basically an unbranded DVI monitor from PC World I believe, would be very surprised if it supported DDC.

Yes I am running Windows 10 in a virtual machine with my GTX 780 Ti (missed the Ti bit out before) passed through to it. DDC doesn't work at all on the Linux side ever, it is only on the DisplayPort connection on the VG248QE with it connected to the Windows VM that DDC works.

How are you switching from Windows to Linux and vice versa?

Peripheral wise just passing them through Libvirt. Monitor wise currently just changing the input source from HDMI to DisplayPort.

$> i2cdetect 6 # X19W
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
30: -- -- -- -- -- -- -- -- 38 39 3a 3b 3c 3d 3e 3f 
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 
70: 70 71 72 73 74 75 76 77     

$> i2cdetect 4 # VG248QE
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- 37 -- -- 3a 3b -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

[rockowitz]

On 5/11/19 6:17 PM, Eden Tyler-Moss wrote: Yeah I also have a second monitor attached (only) to the Vega GPU, it's basically an unbranded DVI monitor from PC World I believe, would be very surprised if it supported DDC. Yes I am running Windows 10 in a virtual machine with my GTX 780 Ti (missed the Ti bit out before) passed through to it. DDC doesn't work at all on the Linux side ever, it is only on the DisplayPort connection on the VG248QE with it connected to the Windows VM that DDC works. How are you switching from Windows to Linux and vice versa? Peripheral wise just passing them through Libvirt. Monitor wise currently just changing the input source from HDMI to DisplayPort.

Try using a Windows application like ClickMonitorDDC or emTech's softMCCS to switch from Windows to Linux.

|$> i2cdetect 6 # X19W 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: -- -- -- -- -- -- -- -- 38 39 3a 3b 3c 3d 3e 3f 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70: 70 71 72 73 74 75 76 77 | |$> i2cdetect 4 # VG248QE 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- 37 -- -- 3a 3b -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- |

—

…

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

[razamatan]

i am also running amdgpu (an r9 280x) and a samsung odyssey g9 over dp. i'm also unable to get ddcutil to correctly address the samsung monitor. do you need me to post the env and interrogate outputs from ddcutil?

[rockowitz]

First, verify that DDC is enabled in the monitor's OSD.  Also, ensure that i2cdetect is installed, as the environment command will use it. Run the following commands and submit the output as attachments, or gist/pastebin links.  Do not include the output inline. ddcutil detect --verbose 2>&1 ddcutil environment --verbose  2>&1 The interrogate output is unnecessary at this time.  interrogate is a superset of the above commands that also runs probe to inspect the monitor's feature set. If you are building your own copy of ddcutil (as opposed to using a prebuilt package), please use the 1.0.0-dev branch. While not critical, its environment command contains additional diagnostics. For what it's worth, until recently I used an R9 280x on this multi-monitor system, which includes a Samsung U32H750 monitor.

…

On 12/19/20 11:07 PM, razamatan wrote: i am also running amdgpu (an r9 280x) and a samsung odyssey g9 over dp. i'm also unable to get ddcutil to correctly address the samsung monitor. do you need me to post the env and interrogate outputs from ddcutil? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMGY3RBQA3CILURZSO7ABTSVVZ65ANCNFSM4DGUFHJQ>.

[TeaObvious]

The problem seems to be, that the G9 does not support DDC over Displayport.
There is no option disable/enable DDC in the OSD and it works out of the box when being connected via HDMI, but not when being connected via Displayport.
Just verified, that this is still the case with the latest firmware update. :(

The "VESA standard monitor" is the G9, the others are connected via Displayport and a Displayport -> DVI adapter.

Detected monitors :

• Device: dev:/dev/i2c-4
  DDC/CI supported: No
  Monitor Name: VESA standard monitor
  Input type: Digital
• Device: dev:/dev/i2c-3
  DDC/CI supported: Yes
  Monitor Name: SyncMaster 245B
  Input type: Digital
  (Automatically selected)
• Device: dev:/dev/i2c-2
  DDC/CI supported: Yes
  Monitor Name: SyncMaster 245B
  Input type: Digital
• Device: dev:/dev/i2c-1
  DDC/CI supported: Yes
  Monitor Name: SyncMaster 245B
  Input type: Digital

[rockowitz]

Just to confirm, have you checked that the DisplayPort connection fails with multiple cables? If so, it's clearly a problem in the monitor's DDC/CI implementation.

@legodev and @razamatan Please run ddcutil detect --verbose 2>&1 and ddcutil environment --verbose 2>&1 when connected using displayport. This may give more information as to how DDC communication is failing. Your monitor can be set to several DisplayPort versions. Does communication fail with all?

Please also run ddcutil interrrogate for the HDMI connection that works. I would like to see details about the features of this monitor.

I have a Samsung U32H750 which from the manuals appears similar to the Odyssey G9 . See my monitor notes It has one of the poorest DDC implementations I've seen in a long time.

[TeaObvious]

@rockowitz Did not try another cable yet, as i don't have another one that is long enough.
My current cable is a rather expensive one, the search term: "KabelDirekt - 8K DisplayPort Kabel Version 1.4" - this cable is VESA certified and does support DP8K.
The output you requested did not change from my post a few months ago: #19 (comment)

There i did both via Displayport and via HDMI. Sadly not with the same GPU, due to the cable length, if you really think its the cable, then i can try via my egpu (which now contains the Vega 56 which i used in my previous comment)

Edit: i see i did not include the detect in my previous post, therefore i attach it here.
detect.txt

Edit2: the "DDC communication failed" on the 2 old SyncMasters is the case, because they where powered off.

Edit3: fixed a typo with the cable length

Edit4: added my current DisplayPort cable name.

[rockowitz]

@legodev No, I don't think the problem is the cable. My suggestion to try a different cable was in the category of dotting i's and crossing t's, to absolutely rule out the cable. @razamatan has the same problem, and it's extremely unlikely that both of you have bad cables.

Based on the information I have so far, I have created an entry the rogues gallery of monitors.

One last thing to verify is that the problem occurs with both DisplayPort inputs, and is unaffected by the chosen DisplayPort version.

[TeaObvious]

I can confirm, that for me it did not work for both DisplayPorts (with Version 1.4, tested previously)

Tested DisplayPort versions on Port 1 with ddcutil detect --verbose and version changed via OSD:

• 1.2 -> not working
• 1.1 -> not working

[rockowitz]

@razamatan That statement from the Display Data Channel wikipedia page is confused. It seems to be saying that, if a Dual-Mode DP connector is not operating in alternative DVI/HDMI mode, but is instead operating in normal DisplayPort mode, then DDC is not supported. That is flat out wrong.

DisplayPort connectors have no dedicated DDC pins. They have pins for the DisplayPort AUX channel. DDC is implemented using the AUX channel, but the AUX channel itself is not DDC. It is general purpose channel that can carry, for example, USB. DisplayPort does not have the I2C SLA/SLC pins (sometimes referred to in this context as DDC pins). See the table at the top of page DisplayPort

A video card with Dual-Mode DP connectors is able to detect that it is communicating with a DVI or HDMI connector at the other end. Per Display Port Dual Mode, "Devices which implement dual-mode will detect that a DVI or HDMI adapter is attached, and send DVI/HDMI TMDS signals instead of DisplayPort signals." In that case the usage of the DisplayPort pins changes, and what are normally the AUX channel pins instead become DDC pins. See the table in the above cited section. A passive adapter routes the pins accordingly, and adjusts voltage levels.

A Dual-Mode DP connector operates as normal when it is communicating with a DisplayPort connector, either on the monitor itself or on an active adapter. An active adapter takes normal DP input on one end, and converts it to DVI/HDMI on the other end. (There are also active adapters that convert DVI/HDMI to DP. I am unaware of any bidirectional adapters.) The DDC (i.e. I2C) signals should be converted as well - if not the EDID could not be read, but it is possible that some active adapters only perform enough conversion to allow for reading the EDID. From the video card's point of view, an active adapter is just a normal DisplayPort connection.

Most video card DisplayPort connectors these days are dual mode, but there may be limitations on the number of connectors that can operate in alternate mode.

That all said, we are left with what you were told in your Samsung chat: The monitor does not support DDC on its DisplayPort connector.

[Erik262]

So please correct me if I didn't understand something. The lack of DDC in the Samsung G9 Monitor is based on a lack of pins/hardware in its connector or is this something which could be still solved by an update?

Are there alternative ways to adjust brightness or volume if there is no DDC??

[rockowitz]

@Erik262 The absence of DDC when using the G9s DisplayPort connection is not a matter of pins. It may be lack of hardware in the monitor, it may be the firmware. DisplayPort does not have dedicated pins for DDC. Instead, it has pins for what is called its AUX channel. DDC, along with many other types of signals, is "multiplexed" over the AUX channel. So the device at either end of a DisplayPort connection, whether video adapter card or monitor, needs to know how to transmit DDC over the AUX channel. To what extent the inability of the monitor support DDC over DisplayPort is a hardware or firmware problem depends, I suppose on the monitor.

You can still use the HDMI connector on the monitor for DDC. That is supported. You have 4 options for a physical connection.

1. HDMI connector on video adapter to HDMI connector on the monitor, using a HDMI-HDMI cable.

2. DVI connector the the video adapter to HDMI connector on the monitor. DVI and HDMI are essentially the same electrically. It's just a matter of routing the appropriate pins on one connector to the corresponding pins on the other.

3. DisplayPort connector on the video adapter to active converter to HDMI connector on the monitor. An "active converter" has the circuitry to convert DP signals to HDMI/DVI signals. The DisplayPort connector on the video adapter thinks it is communicating with a DisplayPort connector on the monitor, and the HDMI connector on the monitor thinks it is communicating with a HDMI connector on the video adapter. Active converters will be labelled "Active".

4. If the video adapter implements Display Port Dual Mode (most do), then it is possible to use a "passive converter" between the DisplayPort connector on the video adapter and the HDMI connector on the monitor. In this situation the video adapter detects that its DisplayPort connector is connected to an HDMI connector on the monitor and modifies its signalling mechanism to the protocol TDMS protocol used by HDMI and DVI. It also uses what are normally the AUX channel pins as simple I2C SDA/SDL pins for communicating DDC. The passive adapter simply routes the wires appropriately, with some voltage adjustment. So the video adapter is in essence using it's DisplayPort connector as a weird HDMI connector to communicate with the HDMI connector on the monitor. Video card DisplayPort connectors that support dual mode should be marked as such. In practice, the connectors on most recent video cards are dual mode, though they area commonly not marked as such.

[razamatan]

i've left feedback to samsung support requesting support for ddc over dp connections for the g9. unfortunately, there's no way to track.

[BinaryLoopCode]

This is really super disappointing. I really want DDC/CI over DisplayPort on the Samsung Odyssey G9.
I used to be able to have the brightness automatically change depending on the time of day with my old monitor (over DisplayPort) but this new 'top of the line' monitor can't.. :(

Adding this comment to add my support and track this thread.

[shantanub08]

3. DisplayPort connector on the video adapter to active converter to HDMI connector on the monitor. An "active converter" has the circuitry to convert DP signals to HDMI/DVI signals. The DisplayPort connector on the video adapter thinks it is communicating with a DisplayPort connector on the monitor, and the HDMI connector on the monitor thinks it is communicating with a HDMI connector on the video adapter. Active converters will be labelled "Active".
4. If the video adapter implements Display Port Dual Mode (most do), then it is possible to use a "passive converter" between the DisplayPort connector on the video adapter and the HDMI connector on the monitor. In this situation the video adapter detects that its DisplayPort connector is connected to an HDMI connector on the monitor and modifies its signalling mechanism to the protocol TDMS protocol used by HDMI and DVI. It also uses what are normally the AUX channel pins as simple I2C SDA/SDL pins for communicating DDC. The passive adapter simply routes the wires appropriately, with some voltage adjustment. So the video adapter is in essence using it's DisplayPort connector as a weird HDMI connector to communicate with the HDMI connector on the monitor. Video card DisplayPort connectors that support dual mode should be marked as such. In practice, the connectors on most recent video cards are dual mode, though they area commonly not marked as such.

Does the 3rd and 4th option takes away all the advantages over DP 1.4? Like, will I be able to run 5120x1440 240 Hz HDR with 3rd or 4th option? Just wanted to confirm.

[rockowitz]

I do not have the expertise to comment specifically on resolution by DP and HDMI version. However, I can make the following general statements:

1. Does the HDMI input on the monitor support the desired resolution? If not, using a DP connector/signal at some point in the chain is irrelevant.

2. Does the HDMI output on the video adapter as well as the input on the monitor support the desired resolution? If so, I imagine option 4 would work. The video adapter is just treating its DP connector as a HDMI connector.

3. Do both the DP output on the video adapter and the HDMI input on the monitor support the desired resolution? In that case it's a question of whether the active adapter being used supports the desired resolution.

[dm17]

Anyone have it working intermittently on one DP, but not another? Also I had it working consistently with the iGPU in the same computer where the dGPU would not. Both dGPU & iGPU were AMDGPU-driven, but the iGPU was over HDMI.

In the case when it isn't working ddcutil detect --verbose shows:
DDC communication failed. (getvcp of feature x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)])