Set VCP write is ignored on an LG display when initial DDC checks are skipped

[Murderlon]

Summary

On an LG UltraGear evo 27GM950B-B, a Set VCP brightness request is consistently ignored when --skip-ddc-checks is used. The same request works when initial DDC checks are enabled.

Verification reports DDCRC_VERIFY, while --noverify exits with status 0 even though the value does not change. A second verified attempt inside the same ddcutil process succeeds when the hidden --i5 2 option is used. Running two separate verified commands does not succeed.

This may indicate that the verification read primes the display and that the second write must reuse the same initialized display handle.

System

Component	Value
Display	LG UltraGear evo 27GM950B-B
Connection	DisplayPort on DP-1
Product code	23800
DDC bus	9
VCP version response	x02 x01
GPU	AMD Radeon 780M using amdgpu
ddcutil	2.2.7 and 2.2.8-DEV at commit 20eee398
Kernel	7.1.9-arch1-2
Distribution	Omarchy 4.0.1-1
Hyprland	0.56.2

The monitor reports VCP feature 0x10 as writable with a range of 0 through 100.

ddcutil-interrogate.txt

FAQ and development branch

I checked the project FAQ. DDC communication is enabled and full checked writes work. The documented picture mode cases do not explain why the result depends on --skip-ddc-checks. The documented sleep multiplier guidance was also tested as described below.

I built the current 2.2.8-dev branch at commit 20eee398. The behavior is unchanged.

skip_status=1 skip_observed=60 skip_elapsed=319ms
i5_status=0 i5_observed=61 i5_elapsed=624ms

Reproduction

Each case below started at 60 and was reset to 60 before the next case.

Skipped checks without verification

$ ddcutil --bus 9 --skip-ddc-checks --noverify setvcp 10 61
$ echo $?
0
$ ddcutil --bus 9 getvcp 10 --brief
VCP 10 C 60 100

Skipped checks with verification

$ ddcutil --bus 9 --skip-ddc-checks --verify setvcp 10 61
Verification failed for feature 10
    Try errors: DDCRC_VERIFY
$ echo $?
1
$ ddcutil --bus 9 getvcp 10 --brief
VCP 10 C 60 100

Full checks without verification

$ ddcutil --bus 9 --noverify setvcp 10 61
$ echo $?
0
$ ddcutil --bus 9 getvcp 10 --brief
VCP 10 C 61 100

Full checks with verification

$ ddcutil --bus 9 --verify setvcp 10 61
$ echo $?
0
$ ddcutil --bus 9 getvcp 10 --brief
VCP 10 C 61 100

Verification retry result

The hidden verification retry option succeeds consistently.

$ ddcutil --bus 9 --skip-ddc-checks --verify --i5 2 setvcp 10 61
$ echo $?
0
$ ddcutil --bus 9 getvcp 10 --brief
VCP 10 C 61 100

Three consecutive tests produced these results.

target=61 status=0 elapsed=624ms
target=62 status=0 elapsed=625ms
target=60 status=0 elapsed=623ms
final_observed=60

By contrast, two separate commands do not reproduce that success.

first_status=1 second_status=1 observed=60 target=61 elapsed=634ms

Both commands in that test used --skip-ddc-checks --verify without --i5.

Other tests

Forcing MCCS 2.2 did not help. Disabling dynamic sleep with fixed multipliers of 1.0 and 2.0 did not help. Every test that retained --skip-ddc-checks left the value unchanged unless --i5 2 was used.

Observed timings were approximately 113 ms for skipped checks without verification, 317 ms for skipped checks with verification, 932 ms for full checks without verification, and 1137 ms for full checks with verification.

Expected behavior

A verified Set VCP request should either apply the requested value or expose a supported retry mechanism that can recover without repeating full initialization on every CLI invocation.

Would it make sense for ddcutil to retry once after a verification mismatch in this case? If automatic retry is undesirable, could the verification retry count receive a stable public option instead of requiring the hidden --i5 option?

The downstream report is omacom/omarchy#8931.

I found #514, but that report appears different because skipped checks generally helped there while full checks failed.

[Murderlon]

I am happy to prepare a PR and verify it on the affected hardware. Before doing so, could you confirm the preferred direction?

1. Automatically retry once after DDCRC_VERIFY, perhaps only with --skip-ddc-checks.
2. Expose a supported option for the verification retry count while leaving the default unchanged.

If an option is preferred, guidance on its name, scope, and whether it should also be exposed through libddcutil would help. I can test the complete regression matrix using the development build.

[rockowitz]

I wrote a long comment on the issue on 9/4, but apparently it was never actually submitted. Here at least is a close to final draft in my files:

First, let me say I appreciate the thoroughness of your research and the clarity of the presentation. Here are my thoughts on the change you propose, starting with background.

Origin of Option --i5

• As best I can tell, option --i5 did not come about because of an issue raised by a user. It was added during a period of work on verification in 2024. Apparently I left it as a utility option because it wasn't clear how to completely handle the retry complexity of setvcp --verify (see below) , nor was It was clear how to properly fit it into the --maxtries interface design. So I left it as an undocumented utility option, providing a hook for further testing.

Retry Levels

Retry for setvcp --verify is possible at several levels. setvcp --verify contains multiple nested sub-operations, similar to but more complicated than the capabilities command. Retry is possible for each sub-operation:

• Writing the setvcp packet, The maxtries setvcp value controls the number of retries.
• The getvcp operaiton that sends a request packet and reads the reply packet. The maxtries getvcp value controls the number of retries.
• In case the getvcp succeeds but doesn't match the expected value, retry by repeatedly executing getvcp and comparing. No retry is implemented at this level.
• Retry the whole setvcp/getvcp/compare operation, which is what --i5 implements

Test Design

There are monitors that change their brightness on a setvcp request, but do not report the changed value. Or perhaps they do not report the changed value immediately. Using a larger change value, e.g. 60->100, would make obvious if this is a factor in your situation.

--skip-vcp-checks

• --skip-ddc-checks is an optimization. If it causes a problem for a particular monitor the user can simply not specify it.
• That said, what is it that doesn't happen when ddc checks are skipped that apparently can cause setvcp to fail for some monitors? If we can figure that out it could be implemented in some way as part of setvcp execution, possibly triggered by an additional option. However, simply incorporating ddc checks as part of setvcp recovery without knowing why is to mix one operation with another.

libddcutil

• In libddcutil ddc checks are always performed, even if option --skip-ddc-checks is specified. libddcutil requires the information the checks provide. It is also cheap in this context, since it occurs once per display when libddcutil is started, or ddca_redetect_displayst() is called, and when a newly attached display is detected.
• In retrospect, including verification as part of ddca_set_non_table_vcp_value(), etc. made the api calls too complex, and client interpretation of the return code unclear. That verification is an option for these functions is the result of having blindly implemented libddcutil API calls corresponding to ddcutil commands. Better practice is for an application to use a separate getvcp call to perform verification, which is what ddcui does. Note that in 2.2.8 ddca_set_non_table_vcp_value()) (the setvcp API call normally used) is deprecated in favour of newly added and simpler ddca_set_non_table_vcp_value2()), which does not have a verification option. Given that, I would not include an API interface to any setvcp --verify enhancements. Any new options, however, would still be specifiable in the ddcutilrc config file.

What is doable in release 2.2.8

• Add a documented, named option that replaces option --i5.
• -Add a --disable-skip-ddc-checks option. If both it and --skip-ddc-checks are specified (e.g. one comes from the command line, another from the config file), --disable-skip-ddc-checks takes precedence.
• If you can identify what it is about ddc checking that makes *--verify always work, and it is a simple operation, it might be possible to add it as a setvcp option.

ddcutil 2.2.8 is in final testing and cleanup before release, which is long overdue. Anything other than simple changes bug fixes and tuning has to wait for the next release.

[rockowitz]

Option --max-setvcp-and-verify-tries has been added to branch 2.2.8-dev. It replaces utility option --i5.

[Murderlon]

I did tests on the display in this issue. The ddcutil version is 2.2.7. The start value was 80/100 for each test. After each write, I
did a separate getvcp 10 with the full DDC checks to find the actual value.

I made a large change, from 80 to 30, on the fast path:

$ ddcutil --bus 9 --skip-ddc-checks --verify setvcp 10 30
Verification failed for feature 10
    Try errors: DDCRC_VERIFY
exit=1
$ ddcutil --bus 9 getvcp 10 --brief
VCP 10 C 80 100

The brightness does not change. The reported value does not change. Therefore the display ignores
the request. The display does not report an old value. DDCRC_VERIFY is correct.

More writes do not correct the problem:

test	actual value
one fast --noverify write to 55	30 (no change)
two fast --noverify writes to 70	30 (no change)
a separate getvcp, then one fast --noverify write to 45	30 (no change)
fast --verify --i5 2 write to 30	30 (correct)
full checks --verify write to 30	30 (correct)

The display ignores the writes in rows 1 to 3. A getvcp in a different ddcutil process does not
help. Row 2 and row 4 have the same number of writes. The difference is the verification read
between the two writes. That read uses the same open handle.

This shows that the DDC checks are not the cause. A read on the same handle immediately before the
write is enough. If this is correct, a new setvcp option can do one getvcp before the write. The
full check sequence is then not necessary.

Times

Each method has three runs. The times are for one full and correct change of the brightness.

• --skip-ddc-checks --verify --i5 2: 455 ms, 565 ms, 628 ms. 3 of 3 correct.
• fast write, then a second write with the full checks: 899 ms, 1315 ms, 1454 ms. 3 of 3 correct.