Verification failed for feature 10

[digitaltrails]

I'm still seeing the very occasional Verification failed for feature 10 on my old HP ZR24w connected by Displayport. It seems to self correct after a few retries, perhaps due to dynamic sleep changes? Once it's OK it seems to stay that way for quite some time (hours, so it's not a easy to trigger in a repeatable way).

ddcutil --enable-dynamic-sleep --force --disable-displays-cache setvcp 10 95 --edid 00ffffffffffff0022f06928010101... 
stderr=Verification failed for feature 10
returned non-zero exit status 1

Could dynamic sleep slowly drift toward unsafe values due to past successes?

Maybe it's the new nvidia driver.

Raising an issue as a place to add further notes.

[rockowitz]

@digitaltrails Just a quick note here to say that I may not have a quick solution. The underlying challenge is that there's no response packet that comes back when a setvcp packet is sent to the monitor. Verification requires a separate getvcp operation that both sends and receives a packet. Just looking at the return code for ddcutil setvcp does not distinguish between communication failures addressable by retry and the monitor simply not acting properly on the setvcp request.

What happens if you use the --noverify option setvcp commands and use a separate getvcp command to check that the value has in fact changed? That would allow you to distinguish between the two cases.

Dynamic sleep should not slowly drift toward unsafe values. Internally there are 11 sleep-multiplier steps ranging from 0 to 2.0. Step 7 corresponds to --sleep-multiplier 1.0. Step 0 corresponds to a sleep-multiplier value of 0.0, and step 10 corresponds to sleep-multiplier 2.0. If an operation requires more than 3 tries, or the average number of tries over recent successful operations is greater than 1.4, the step level is increased. If the average number of tries over recent operations is less than 1.1, the step level is decreased. If a retryable failure occurs, the step is immediately increased by an amount reflecting the number of tries remaining for the given operation. Typically what I see is a small oscillation of at most a couple steps.

[digitaltrails]

I'd not noticed any problems until after moving to Nvidia 535.54.03. I've backed out the Nvidia 535.54.03 driver to 525.116.04 to see if it's driver related. I'm seeing another issue related to 525.54.3 (but not to do with DDC/ddcutil), perhaps 525.54.3's a bad vintage.

No one else is complaining, and the problem self corrects, I'm in no hurry for a solution. I could go down the --noverify route, but I'll let the dust settle on all the surrounding pieces first.

[akdevservices]

It seems that ddcutil 2.0.0 have problems with ddcutil dynamic adjustments. I experience the similar problem as the topic starter does (though the vcp feature is different). Deletion of $XDG_CACHE_HOME/ddcutil directory helps. Auto-adjusting procedure is probably too agressive.

[digitaltrails]

I've been using 2.0.0 for some time now with no further issues (although vdu_controls does do it's own retries, so it's possible I wouldn't notice the odd error).

I've also moved to Nvidia 535.113.01. The latest Nvidia driver with ddcutil still cannot detect one of my monitors when connected DisplayPort-DVI, but the driver seems to be playing fine with ddcutil otherwise (issue #321).

[fionnb]

It seems that ddcutil 2.0.0 have problems with ddcutil dynamic adjustments

I can confirm. After upgrading to to ddcutil-git 2.0.0.r1.g5d5bd6c1, I started getting "Verification failed for feature 10" messages instead of brightness changes. I am running a very recent AMD APU (780M) on kernel 6.5.9.

The fix described by @akdevservices (removing ddcutil's cache directory) made the problem go away immediately. I am still getting messages like busno=17, Feature 0x00 should not exist but ddc_get_nontable_vcp_value() succeeds, returning mh=0xff ml=0xff sh=0x00 sl=0xff on every invocation, though - without any noticeable functional consequences.

[rockowitz]

@fionnb The issue of the benign but confusing messages was discussed on issue #348. As noted there the message indicates your monitor does not adhere to the DDC/CI spec when replying to a getvcp request for a non-existent feature. It simply makes up an answer. Branch 2.0.2-dev has been changed to hopefully make the message less alarming, and the message is emitted only for verbose output.

Removing file $HOME/.cache/ddcutil/dsa discards the accumulated dynamic sleep data. If the dynamic sleep problem persists on branch 2.0.2-dev, please run with option --istats and submit the output, along with the current dsa cache file, as attachments.

Note that option --disable-dynamic-sleep turns off the dynamic sleep adjustments. You can still use --sleep-multiplier to set a constant multiplier. However, while running from branch 2.0.2-dev I would prefer that problems be encountered and reported.

[fionnb]

Removing the cache turns out to be only a temporary solution. Apparently once a cache has been rewritten, ddcutil fails again. I am still on 2.0.0, btw. While playing around with options to prevent this, I came across the additional issue that the manpage documents an option --disable-displays-cache but using that yields an "Unknown option --disable-displays-cache" error message. Just thought you might want to know.

[digitaltrails]

Have you tried setting --sleep-multiplier to 1.0? Setting a manual multiplier should disable any auto tuning.

(Sorry about the misleading advice on this - my recollections were not as good as actually checking the manual first.)

[rockowitz]

To disable the dynamic sleep algorithm, use option --disable-dynamic-sleep. If that option is in effect, the sleep multiplier used is the value given on the --sleep-multiplier option, or 1.0 if -sleep-multiplier is not used. If dynamic sleep is disabled, accumulated statistics are retained (i.e. file $HOME/.cache/ddcutil/dsa is not erased) and will be used the next time dynamic sleep is enabled.

If option --disable-dynamic-sleep is not specified, (i.e. --enable-dynamic-sleep is in effect) and --sleep-multiplier is specified, then existing sleep stats are erased and the dynamic sleep algorithm starts working using the specified multiplier. If neither of these options are given, the dynamic sleep algorithm works as normal.

If option --discard-caches dsa, --discard-caches all, or simply --discard-caches is specified, dynamic sleep data is always discarded at the start of a command. (--discard-caches can also be written as --discard-cache.)

There is also command ddcutil discard caches which simply erases caches and does nothing else, but it is not currently working. It will be fixed in release 2.0.2-dev.

Option --disable-displays-cache is for a different kind of caching that was intended for release 2.0. It turned out the checks required to properly handle things like display connection/disconnection and sleep largely negated the performance gains of that kind of caching, and it was never released. The man page needs to corrected.

Bear in mind that there are significant changes to the dynamic sleep algorithm in branch 2.0.2-dev. Bug reports regarding dynamic sleep in release 2.0.0 are generally irrelevant at this point.

[menkaur]

I'm having a similar issue on arch zen 6.6.1 with ddcutil 2.0.0 Following command used to work, but now returns error:

sudo ddcutil --verbose setvcp 10 90 --display 1
Feature definition file not found: DEL-DELL_U2412M-41083.mccs Verifying that value of feature 0x10 successfully set... Current value does not match value set. Verification failed for feature 10

I've tried deleting ~/.cache/ddcutil/ directory, it didn't fix the issue

[rockowitz]

@menkaur Does the problem persist with branch 2.0.2-dev?

Does using option --disable-dynamic-sleep resolve the problem?

Is it the case that the visible brightness of the monitor does not change, or that it does change but verification of the value of feature x10 fails?

[menkaur]

Yes, --disable-dynamic-sleep fixes the issue The brightness of the monitor did not change, that is why I was investigating what was wrong

On Sat, Nov 18, 2023 at 1:48 AM rockowitz @.***> wrote:

@menkaur https://github.com/menkaur Does the problem persist with branch 2.0.2-dev?

Does using option --disable-dynamic-sleep resolve the problem?

Is it the case that the visible brightness of the monitor does not change, or that it does change but verification of the value of feature x10 fails?

— Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/323#issuecomment-1817377653, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABJ7WXYF2XQHPEN2BMRGJTYFA4ZNAVCNFSM6AAAAAAZTOU5G6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGM3TONRVGM . You are receiving this because you were mentioned.Message ID: @.***>

[rickalex21]

Same issue here:

sudo ddcutil --verbose setvcp 10 90 --display 2
Feature definition file not found: AOC-27B1-9985.mccs
Verifying that value of feature 0x10 successfully set...
Current value does not match value set.
Verification failed for feature 10

[rockowitz]

I have a hunch as to how the dynamic sleep algorithm is causing setvcp failures and have hacked some code into branch 2.0.2-dev that should at least confirm the hunch.

Background: Most DDC/CI transactions (e.g. getvcp) consist of a request packet sent to the monitor, followed by a reply packet read from the monitor. The dynamic sleep algorithm measures the error rate of this transaction pair and adjusts the sleep-multiplier accordingly.

A handful of DDC/CI transactions in particular setvcp, consist only of a request packet sent to the monitor. All that ddcutil knows is that the packet has been received. For this reason, unless --noverify is specified, ddcutil follows up with a getvcp operation to check that the new value has been set. Currently, the dynamic sleep algorithm uses the sleep multiplier calculated from request/reply interactions for setvcp operations as well. I suspect this is the source of the errors.

As a hack, the sleep-multiplier applied after sending the setvcp request packet is never less than 1.0. Whenever this hack is applied, a message is written to the system log. (Use journalctl --follow -t ddcutil to track.)

Please let me know whether or not his hack solves the problem; if it does then it should be possible to create a cleaner solution.

[awkto]

I may have found a fix for this. I had the same problem on Lenovo monitors from a lenovo thinkpad with Fedora 39.

On the same laptop I had 2 monitors that are exactly, the same. One worked, one did not, with ddcutil.

Manually going through the monitor settings I saw that Dynamic Contrast was enabled (see screenshot).

Fix : Disable Dynamic Contrast on the monitor settings, and ddcutil should start working. It did for me!

[grafov]

I've got this problem on old NEC 2090UXi and carefully read this tread. And the latest comment above just point me to the right way. Thank you @awkto! I've found the setting "auto brightness ON" in menu of the monitor. Turning it off make setvcp working!

ddcutil --verbose -d 1 setvcp 10 50
Feature definition file not found: NEC-LCD2090UXi-26288.mccs
Verifying that value of feature 0x10 successfully set...
Verification succeeded

This NEC model just have ambient light detector. But I moved to more smart Arduino solution with ambient sensor for setting same parameters on all my monitors :)

It seems when you got this issue you firstly should check your monitor menu for different "auto" or "dynamic" options.

[rothn]

This affects me with the open-source NVIDIA driver (not Noveau but not the proprietary one either-- the one from NVIDIA that is technically open-source by calling stub functions in the firmware), running Plasma 6.0.2 with Wayland on a fully-updated (as of 5 minutes ago) Arch Linux install.

Ubuntu 22.04 LTS with X11, brightness control works just fine. EDIT 2024-04-13: Brightness controls no longer work on Ubuntu.

I'm running a Zotac 3090 on ROG CROSSHAIR VII HERO (WI-FI) so I don't think these workarounds would work for me.

The --disable-dynamic-sleep flag does not fix the issue for me.

[digitaltrails]

This affects me with the open-source NVIDIA driver (not Noveau but not the proprietary one either-- the one from NVIDIA that is technically open-source by calling stub functions in the firmware), running Plasma 6.0.2 with Wayland on a fully-updated (as of 5 minutes ago) Arch Linux install.

Ubuntu 22.04 LTS with X11, brightness control works just fine.

I'm running a Zotac 3090 on ROG CROSSHAIR VII HERO (WI-FI) so I don't think these workarounds would work for me.

The --disable-dynamic-sleep flag does not fix the issue for me.

I've had problems with different versions of Nvidia's drivers before. I only use the proprietary driver, but presumably the stubs driver you mention might be using the same firmware. Anyway my problem persisted until eventually the driver was updated, but in the mean time I found changing to DisplayPort cables was a workaround. See issue #321 if this seems of any interest.

[missonserch]

I have a Samsung LS25BG400EUXEN (Odyssey G25) It apparently responds with it's 'Picture Mode' on feature 0x10 instead of brightness, i.e if 'Custom' mode is set, response is always 0, if 'sRGB' response is 5. How to workaround this? I would really like to change brightness with media keys, instead of my current solution of binding modifier + number keys to set specific brightness.

[rockowitz]

@missonserch Your comment is unrelated to this issue. It has been moved to #396