Samsung U32J59x only works on DisplayPort

[fritz-m-h]

Hey,

this is my first post here so I hope to do everything right and so on.

As you can see in the attached file, I own two almost identical Samsung U32J59x and one of them is connected to my PC via HDMI and the other one via DisplayPort. Additionally, I tested the one of them which I normally connect via DisplayPort on a different PC via HDMI and the HDMI results always show, that DDC was not supported by the screen, while I successfully tested the adjustment of the brightness of the DisplayPort screen. Unfortunately I only have one DisplayPort connector on my PC, so I somehow have to deal with HDMI, and I don't even know, if it's my fault or not. Could you please consider helping me in any way? Thank you very much.

interrogate.txt

[fritz-m-h]

Additionally, the other HDMI port which supports only 30Hz does support DDC control. Weird, isn't it?

[rockowitz]

Welcome to the world of Nvidia's proprietary driver. Tty using the special settings described at Special Nvidia Driver Settings.

[fritz-m-h]

Thank you for reply! Unfortunately, the second PC I tested it with has an Intel Graphics Card and the same issue :/

[rockowitz]

You appear to be having data problems. The only thing that ddcutil can do at that point is increase its sleeps between operations. Try using option --sleep-multiplier 2.0.

That said, you can try to glean more detail on the errors. Option --ddc reports DDC packet data errors. Options --trcfunc ddc_write_read_with_retry --trcfunc ddc_write_read will dump out voluminous trace information at the layer where the data errors are detected. Use them with a simple command such as detect.

For example:

ddcutil detect --ddc --trcfunc ddc_write_read_with_retry --trcfunc ddc_write_read

[fritz-m-h]

Please excuse the belated reply, I executed $ ddcutil detect --ddc --trcfunc ddc_write_read_with_retry --trcfunc ddc_write_read --sleep-multiplier 2.0 and unfortunately got similar errors:

interrogate_v2.txt

[rockowitz]

The DDC get feature reply packets contain garbage that's not even close to what is expected. This will be more apparent if you just use option --ddc. That DDC communication works on the slower 30hz HDMI connector suggests its an issue in the monitor's DDC implementation.