iiyama fails verify, needs "ddcutil scs" to apply settings

[ranma]

I recently got a new iiyama Monitor (XUB2792QSU-B1) and was initially frustrated that ddcutil seemed to be only able to read the settings, but not set them.

interrogate.txt

After some trial and error I found that some settings worked (e.g. "Feature: 04 (Restore factory defaults)" and "Feature: 60 (Input Source)").

Finally I stumbled across this comment: https://github.com/rockowitz/ddcutil/issues/32#issuecomment-405234033

And it turns out that for this monitor "ddcutil scs" is needed to apply most settings. Additionally I also need to set "--noverify" since otherwise I get an error on the setvcp call: (ddc_write_read_with_retry) Display_Handle[i2c: fh=3, busno=1], ddc_write_read() succeeded after 1 sleep and retry for DDC Null Response Verification failed for feature 10

It would be nice if this could be auto-detected.

Lastly, in case someone finds this useful: The service menu on this monitor can be entered by holding all buttons except "<" while powering on, then the INPUT button will bring up the (minimal) service menu, allowing to enable/disable a burn-in mode and also to reprogram the color temperature preset RGB values.

[rockowitz]

Interesting monitor and configuration you've got there.

"ddcutil scs" was implemented for completeness - it was trivial to do.  Some monitors claim to support the command, some do not. This is the first monitor for which it actually appears to do something.

To clarify what you observed, normally ddcutil internally does a getvcp after a setvcp to see if the feature value has actually changed.  This verification is not performed for write-only features like x04.  There are also some other special cases where verification is skipped. Feature x60 changes the monitor's input source away from the current system, so a subsequent getvcp will fail.

Short of adding a table of monitor quirks, I don't offhand see how to automatically detect the need for scs.  What is doable is a command line option named something like "--setvcp-requires-scs" to indicate that a Save Current Settings request should be sent after setting  a feature value  Would this satisfy your needs?

I see that there are 2 connections to the monitor, a DisplayPort connection with I2C device /dev/i2c-1 and a DVI connection with I2C device /dev/i2c-3.  Do you experience the same problem on both connections?  Why are there 2 connections?

Both amdgpu and the older radeon driver are loaded.  Is this intentional?

Finally, this monitor exhibits what I call the "overeager student syndrome".  Ask it the value for any  feature number, and it will always return an answer. The "unsupported feature" bit never set in the response.  A few monitors misuse the DDC Null Message  to indicate an unsupported feature, and a fewer number still set all value bytes in the response (MH, ML, SH, SL) to 0. ddcutil can cope with those situations.  But this monitor gives no indication that a feature is unsupported.

Also of note: the VCP version in the capabilities string is 2.2, but the version reported by feature xDF is 2.1.

On 8/2/20 4:45 PM, ranma wrote:

I recently got a new iiyama Monitor (XUB2792QSU-B1) and was initially frustrated that ddcutil seemed to be only able to read the settings, but not set them.

interrogate.txt https://github.com/rockowitz/ddcutil/files/5012886/interrogate.txt

After some trial and error I found that some settings worked (e.g. "Feature: 04 (Restore factory defaults)" and "Feature: 60 (Input Source)").

Finally I stumbled across this comment: #32 (comment) https://github.com/rockowitz/ddcutil/issues/32#issuecomment-405234033

And it turns out that for this monitor "ddcutil scs" is needed to apply most settings. Additionally I also need to set "--noverify" since otherwise I get an error on the setvcp call: (ddc_write_read_with_retry) Display_Handle[i2c: fh=3, busno=1], ddc_write_read() succeeded after 1 sleep and retry for DDC Null Response Verification failed for feature 10

It would be nice if this could be auto-detected.

Lastly, in case someone finds this useful: The service menu on this monitor can be entered by holding all buttons except "<" while powering on, then the INPUT button will bring up the (minimal) service menu, allowing to enable/disable a burn-in mode and also to reprogram the color temperature preset RGB values.

— 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/136, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3WIMCW7IGOFIQQJBTLR6XF53ANCNFSM4PSXISOA.

[ranma]

What is doable is a command line option named something like "--setvcp-requires-scs" to indicate that a Save Current Settings request should be sent after setting a feature value Would this satisfy your needs?

Well for my purposes I can just use "ddcutil --noverify setvcp $reg $data && ddcutil scs", so no new option is necessary. There would indeed be need for some sort of quirks table to make this automatic.

I see that there are 2 connections to the monitor, a DisplayPort connection with I2C device /dev/i2c-1 and a DVI connection with I2C device /dev/i2c-3. Do you experience the same problem on both connections? Why are there 2 connections?

For debugging I was trying out both, they behave the same.

Both amdgpu and the older radeon driver are loaded. Is this intentional?

I just upgraded the GPU, the previous one used the radeon driver, so I currently have both compiled into the kernel.

But this monitor gives no indication that a feature is unsupported.

At least all commands reported by "ddcutil capabilities" seem to work, I haven't tried any of the unsupported ones.

[Tom-Brouwer]

@rockowitz I came across this issue because I also had trouble using ddcutil on a Iiyama display (XUB2492HSU), so perhaps it's not as rare as it may seem. Just to confirm, if I do ddcutil setvcp 10 50 --bus=0, I get:

(ddc_write_read_with_retry) Display_Handle[i2c: fh=3, busno=0], ddc_write_read() succeeded after 1 sleep and retry for DDC Null Response
Verification failed for feature 10

and nothing happens. As said above, when I use `ddcutil setvcp 10 50 --bus=0 --noverify && ddcutil scs, it does work. In my case the display is connected through displayport, using a displayport to HDMI converter, to the HDMI port of the display. Here's my interrogate.txt

[rockowitz]

Thanks for posting the information about your monitor.  It seems the need for SCS is common to Iiyama displays.  Also, as with the case with the XUB2792QSU, the interrogate output shows that  getvcp never reports a feature as unsupported, it just returns garbage.

 On 10/23/20 7:29 AM, Tom-Brouwer wrote:

@rockowitz https://github.com/rockowitz I came across this issue because I also had trouble using ddcutil on a Iiyama display (PL2492H), so perhaps it's not as rare as it may seem. Just to confirm, if I do |ddcutil setvcp 10 50 --bus=0|, I get:

|(ddc_write_read_with_retry) Display_Handle[i2c: fh=3, busno=0], ddc_write_read() succeeded after 1 sleep and retry for DDC Null Response Verification failed for feature 10 |

and nothing happens. As said above, when I use `ddcutil setvcp 10 50 --bus=0 --noverify && ddcutil scs, it does work. In my case the display is connected through displayport, using a displayport to HDMI converter, to the HDMI port of the display. Here's my interrogate.txt https://github.com/rockowitz/ddcutil/files/5429150/interrogate.txt

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/136#issuecomment-715284702, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3X3NLCTVIOH4LMKYH3SMFSJTANCNFSM4PSXISOA.

[DarrenCook]

I've got the same monitor, and arrived here after getting the "verification failed for feature 10" error. In my case just adding --noverify was enough, so no need for scs. So these both work:

 sudo ddcutil --noverify --model PL2792Q setvcp 10 100
 sudo ddcutil --noverify --model PL2792Q setvcp 10 0

I'm connecting with HDMI, in case that might be the difference? Or maybe brightness control is one that doesn't need it?

(Now I just need to put together a bash script to be able inc/dec the brightness, drop the need for sudo, and attach it to a couple of keyboard shortcuts. I'm happy with the monitor, but the OSD UX is soul-destroying.)

[rockowitz]

@DarrenCook Thank you for posting your experiences with this monitor. It helps everyone. I assume the monitor is changing brightness after each of the setvcp commands. What values do get from "ddcutil getvcp 10" after each setvcp call?

Re the bash script, I just want to make sure you're aware of relative setvcp commands, e.g. "setvcp 10 + 20", and that --brief output is generally formatted to simplify screen-scraping.

As for OSDs, I agree they're generally painful. The jog button that seems to be in vogue now makes the OSD even harder to use. Unfortunately, more and more functionality is controlled by manufacturer specific command sequences, so you're forced to use it. The only real solution to discovering these command sequences is to sniff the I2C packets on the cable when using a Windows program that knows how to control the monitor.

[DarrenCook]

The getvcp calls match what I just set (and the monitor appearance has changed).

e.g. "setvcp 10 + 20",

I couldn't get this to work (+ or -)... ah, just noticed I have version 0.8.6 installed, which looks to be 3 years old. So that might be related to why I get different behaviour to the OP!

If/when I install the latest version I'll add a note if behaviour has changed.

[rockowitz]

The parsing of relative vcp values is, well, odd. The spaces around the + or - sign are necessary to get around the command line parsing that happens before ddcutil is started. IIRC there was also a bug in the parsing that I fixed a couple years ago. 0.8.6 is ancient. You really want to be on a current version. As you've probably noticed, 1.1.0 is in the release candidate phase.

[evadim]

Going to add some chaos. I have two identical PL2792Q monitors connected via Dell thunderbolt dock station, DP cables. Difference is in manufacture date: one 2018, Week: 6 and another 2020, Week: 20.

For both input selection works without additional flags. New one can be managed with --noverify flag Older can not and ddcutil scs also don't help...