Verification failed for feature 10 about ddcutil HOT 20 OPEN

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.

from ddcutil.

@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.

from ddcutil.

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.

from ddcutil.

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.

from ddcutil.

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).

from ddcutil.

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.

from ddcutil.

@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.

from ddcutil.

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.

from ddcutil.

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.)

from ddcutil.

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.

from ddcutil.

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

from ddcutil.

@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?

from ddcutil.

from ddcutil.

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

from ddcutil.

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.

from ddcutil.

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!

from ddcutil.

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.

from ddcutil.

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.

from ddcutil.

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.

from ddcutil.

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

from ddcutil.