Problem using dynamic-sleep with Beng TT2200HD

[digitaltrails]

In 2.0.0-dev dynamic sleep appears to be on by default. With a Beng TT2200HD, the capabilities operation mainly fails:

% ddcutil --enable-dynamic-sleep capabilities
(app_get_capabilities_string) !!! Unable to get capabilities for monitor on Display_Handle[i2c-3: fd=3 @0x55677fb40960]
(app_get_capabilities_string   ) Unexpected status code: DDCRC_ALL_RESPONSES_NULL(-3011): all tries returned DDC Null Message

I think sometimes eventually succeeds because I seen the error go away once, after which the capabilities are cached (not 100% sure how it went away). If I remove the cache the problem resurfaces.

On the other hand --disable-dynamic-sleep always works:

% ddcutil --disable-dynamic-sleep capabilities ## WORKS Model: T2200HD MCCS version: 2.0 Commands: Op Code: 01 (VCP Request) Op Code: 02 (VCP Response) ...

The problem seems to cause following getvcp/setvcp to fail. This seems to stop being a problem once capabilities are cached by running ddcutil --disable-dynamic-sleep capabilities.

I think this may be similar to the transient issue I was seeing with my HP ZR24.

Maybe the default for capabilities should be --disable-dynamic-sleep

The dsa file after the capabilities error run looks like:

FORMAT 2
* DEV  /dev/i2c device
* EC   EDID check sum byte
* C    current step
* I    interval remaining
* DEV EC C I Values
* Values {tries required, step, epoch seconds}
i2c-3 2a 1 3 10 {1,10,1688159364} {1,7,1688159364} {1,7,1688159364} {1,7,1688159364} {1,7,1688159366} {1,6,1688159366} {1,5,1688159366} {1,4,1688159366} {1,3,1688159366} {1,2,1688159366}

The dsa after things are settled is:

FORMAT 2
* DEV  /dev/i2c device
* EC   EDID check sum byte
* C    current step
* I    interval remaining
* DEV EC C I Values
* Values {tries required, step, epoch seconds}
i2c-3 2a 5 3 5 {2,5,1688158861} {2,5,1688158862} {2,5,1688158863} {2,5,1688158865} {2,5,1688158866} {2,5,1688158867} {2,5,1688158869} {2,5,1688158870} {2,5,1688158872} {2,5,1688158874} {2,5,1688158875} {2,5,1688158877} {2,5,1688158878} {2,5,1688158879} {2,5,1688158880} {2,5,1688158881} {2,5,1688158882} {2,5,1688158884} {2,5,1688158885} {2,5,1688158886}

[digitaltrails]

--f10 makes the Beng much more laggy (when dynamic sleep is enabled). The Beng is mostly OK without it. I'm getting the odd error when dragging the brightness slider, but strangely, not with the looping getvcp/setvcp bash-script.

The errors might have something to do with background threads also accessing ddcutil - vdu_controls uses a lock to prevent concurrent use of ddcutil, perhaps it's rapid sequential use (perhaps its more rapid than a script). It's very rare, the Beng is a bit of a clunker, perhaps that's just the way things are.

09:45:14 DEBUG: subprocess result: error  Display-2 ddcutil --enable-dynamic-sleep --force setvcp 10 90 --edid 00ffffffffffff0009d12677455400... stderr='Verification failed for feature 10
', exception=Command '['ddcutil', '--enable-dynamic-sleep', '--force', 'setvcp', '10', '90', '--edid', '00ffffffffffff0009d12677455400003312010380301b782e3581a656489a24125054a54b00714f8180d1c001010101010101010101023a801871382d40582c4500dd0c1100001e000000ff003243383033353237534c300a0a000000fd00384c1e5311000a202020202020000000fc0042656e5120543232303048440a002a']' returned non-zero exit status 1.
09:45:14 DEBUG: TRACEBACK:   File "/home/michael/Projects/vdu_controls/vdu_controls.py", line 7495, in <module>

[rockowitz]

@digitaltrails I'm so glad you rescued the Benq from the dump. It's really helpful (for me at least) that you have a reliably unreliable monitor to test against. I should think that's helpful for vdu_controls as well.

Have you tested trying to getvcp unsupported feature codes on this monitor.?

I'm not surprised that the --f10 option makes ddcutil perceptibly slower. It uses a few extremely long sleeps attempting to recover from a Null Message. It's a vestige of an early dynamic sleep implementation

Concurrency is a nasty problem. libddcutil allows only one of its threads to "open" a /dev/i2c device. However, there's no concurrency checking across multiple libddcutil and ddcutil instances, let alone versus other applications. Down the line I'd like to create a daemon version of libddcutil, but that's way down the line.

[digitaltrails]

I'm seeing a lot of these in the systemd journal from when my monitors are suspended:

busno=3, Testing for unsupported feature 0x41 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]

By suspended I mean from doing:

loginctl lock-session
xset dpms force suspend

The light metering and sun-angle scheduling in vdu_controls continues running during "suspend".

My LG 4K is on bus-3 (if that's USB bus), so it's not really Beng related.

[digitaltrails]

@digitaltrails I'm so glad you rescued the Benq from the dump. It's really helpful (for me at least) that you have a reliably unreliable monitor to test against. I should think that's helpful for vdu_controls as well.

Yes, it turned out to be a good last minute intervention.

Have you tested trying to getvcp unsupported feature codes on this monitor.?

I just did a getvcp 22, it reported

VCP code 0x22 (Horizontal Size               ): Unsupported feature code ((null))

I'm not surprised that the --f10 option makes ddcutil perceptibly slower. It uses a few extremely long sleeps attempting to recover from a Null Message. It's a vestige of an early dynamic sleep implementation

Fortunately it doesn't appear to be needed. The number of errors from the Beng has dropped to quite infrequent - as least as far as using vdu_controls is concerned. The current dsa file, in case it's of interest (the beng is i2c-1):

FORMAT 2
* DEV  /dev/i2c device
* EC   EDID check sum byte
* C    current step
* I    interval remaining
* L    current lookback
* DEV EC C I L Values
* Values {tries required, step, epoch seconds}
i2c-0 3d 0 3 5 {1,0,1689902541} {1,0,1689902541} {1,0,1689902541} {1,0,1689902542} {1,0,1689902542} {1,0,1689902542} {1,0,1689902542} {1,0,1689902543} {1,0,1689902543} {1,0,1689902543} {1,0,1689902609} {1,0,1689902609} {1,0,1689902609} {1,0,1689902610} {1,0,1689902610} {1,0,1689902610} {1,0,1689902610} {1,0,1689902611} {1,0,1689902611} {1,0,1689902611}
i2c-1 2a 6 3 20 {1,7,1689902474} {1,6,1689902474} {1,7,1689902475} {1,6,1689902475} {1,5,1689902475} {1,7,1689902476} {1,6,1689902541} {1,7,1689902542} {1,6,1689902542} {1,7,1689902543} {1,6,1689902543} {1,5,1689902543} {1,7,1689902544} {1,6,1689902609} {1,7,1689902610} {1,6,1689902610} {1,7,1689902611} {1,6,1689902611} {1,5,1689902611} {1,7,1689902612}
i2c-3 9e 0 3 5 {1,0,1689902542} {1,0,1689902542} {1,0,1689902542} {1,0,1689902543} {1,0,1689902543} {1,0,1689902543} {1,0,1689902544} {1,0,1689902544} {1,0,1689902544} {1,0,1689902544} {1,0,1689902610} {1,0,1689902610} {1,0,1689902610} {1,0,1689902611} {1,0,1689902611} {1,0,1689902611} {1,0,1689902612} {1,0,1689902612} {1,0,1689902612} {1,0,1689902612}

Concurrency is a nasty problem. libddcutil allows only one of its threads to "open" a /dev/i2c device. However, there's no concurrency checking across multiple libddcutil and ddcutil instances, let alone versus other applications. Down the line I'd like to create a daemon version of libddcutil, but that's way down the line.

If it was just a Linux oriented daemon, a dbus based daemon might fit in.

[rockowitz]

The x41 error is perplexing. We know the LG monitor properly reports unsupported features. We only test for unsupported features after an always good feature (x10) is checked. So it surprises me that the x10 check apparently produced a valid response, but the x41 test did not. The error should be benign. ddcutil sets the normal flag DREF_DDC_USES_DDC_FLAG_FOR_UNSUPPORTED in this situation.

The next batch of changes will include additional syslog messages for the relevant sections of code. For now, what happens if you disable dynamic sleep and instead set a relatively high (1.0ish) sleep-multiplier value? Do you still see the messages?

[digitaltrails]

The x41 error is perplexing. We know the LG monitor properly reports unsupported features. We only test for unsupported features after an always good feature (x10) is checked. So it surprises me that the x10 check apparently produced a valid response, but the x41 test did not. The error should be benign. ddcutil sets the normal flag DREF_DDC_USES_DDC_FLAG_FOR_UNSUPPORTED in this situation.

The next batch of changes will include additional syslog messages for the relevant sections of code. For now, what happens if you disable dynamic sleep and instead set a relatively high (1.0ish) sleep-multiplier value? Do you still see the messages?

I've seen my HP monitor (bus-0) report a few of these today, not as many as the LG. As you suggest, I will disable dynamic sleep and see if the errors go away.

[digitaltrails]

The x41 error is perplexing. We know the LG monitor properly reports unsupported features. We only test for unsupported features after an always good feature (x10) is checked. So it surprises me that the x10 check apparently produced a valid response, but the x41 test did not. The error should be benign. ddcutil sets the normal flag DREF_DDC_USES_DDC_FLAG_FOR_UNSUPPORTED in this situation. The next batch of changes will include additional syslog messages for the relevant sections of code. For now, what happens if you disable dynamic sleep and instead set a relatively high (1.0ish) sleep-multiplier value? Do you still see the messages?

I've seen my HP monitor (bus-0) report a few of these today, not as many as the LG. As you suggest, I will disable dynamic sleep and see if the errors go away.

These errors are still happening with dynamic sleep disabled, but as I mentioned before, I think it's when the LG is asleep (xset dpms force suspend).

[rockowitz]

That's useful to know. It strongly suggests the problem is associated with the monitor being suspended.

I've added more syslog messages in the monitor detection code to better understand what is going on. Be sure to run with option --syslog debug to ensure that all possible syslog messages are emitted.

I've also added another pair of experimental options to dynamic sleep. Option --i1 specifies the minimum multiplier step allowed. Option --fl1 specifies a minimum multiplier value, which is converted to a step. By default, the minimum multiplier step is 0. The intent is twofold. First, reduce jitter in the multiplier step. The second is to reduce the (very unlikely) possibility of maximum retries for DDC Null Message being exceeded when in fact it is recoverable.

[digitaltrails]

I put the HP and LG monitors into dpms force suspend at around 3pm and went away for a cup of tea. The log accumulated the following in repeats until I returned (this would be with dynamic sleep enabled):

Jul 23 15:03:46  ddcutil[32544]: busno=3, sleep-multiplier =  2.00. Testing for supported feature 0x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:03:48  ddcutil[32544]: busno=3, sleep-multiplier= 1.00. Retesting for supported feature 0x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:03:49  ddcutil[32544]: busno=3, sleep-multiplier= 1.00, Testing for unsupported feature 0x41 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:03:51  ddcutil[32544]: busno=3, sleep-multiplier= 1.00, Testing for unsupported feature 0xdd returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:03:52  ddcutil[32544]: busno=3, sleep-multiplier= 1.00, Testing for unsupported feature 0x00 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:03:52  ddcutil[32544]: busno=3, DDCRC_RETRIES failure reading all unsupported features. Setting DREF_DDC_USES_DDC_FLAG_FOR_UNSUPPORTED
Jul 23 15:03:56  ddcutil[32567]: busno=3, sleep-multiplier =  2.00. Testing for supported feature 0x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:03:58  ddcutil[32567]: busno=3, sleep-multiplier= 1.00. Retesting for supported feature 0x10 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:03:59  ddcutil[32567]: busno=3, sleep-multiplier= 1.00, Testing for unsupported feature 0x41 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:04:00  ddcutil[32567]: busno=3, sleep-multiplier= 1.00, Testing for unsupported feature 0xdd returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:04:02  ddcutil[32567]: busno=3, sleep-multiplier= 1.00, Testing for unsupported feature 0x00 returned Error_Info[DDCRC_RETRIES in ddc_write_read_with_retry, causes: DDCRC_DDC_DATA(10)]
Jul 23 15:04:02  ddcutil[32567]: busno=3, DDCRC_RETRIES failure reading all unsupported features. Setting DREF_DDC_USES_DDC_FLAG_FOR_UNSUPPORTED``

[rockowitz]

That's actually a relief to know that a supported feature is failing similarly to the unsupported ones. But it looks like only one of the monitors was generating errors. From prior logs I assume that /dev/i2c-3 is the Benq.

[digitaltrails]

That's actually a relief to know that a supported feature is failing similarly to the unsupported ones. But it looks like only one of the monitors was generating errors. From prior logs I assume that /dev/i2c-3 is the Benq.

The Beng is i2c-3 on my old test machine. I added the Beng it to my main desktop to see if the GPU/GPU-driver change would make any difference (plus I needed to test vdu_controls with more than two monitors). On my main desktop, the LG is i2c-3, HP i2c-0, and Beng i2c-1. The errors only occur with the LG and only when in the state xset dpms force suspend. The ports on the GPU seem arbitrarily named because the BIOS chooses to use display i2c-3 which I presume is the first. Full ID details below.

Display 1
   I2C bus:  /dev/i2c-0
   DRM connector:           card0-DP-1
   EDID synopsis:
      Mfg id:               HWP - Hewlett Packard
      Model:                HP ZR24w
      Product code:         10345  (0x2869)
      Serial number:        CNT00811J6
      Binary serial number: 16843009 (0x01010101)
      Manufacture year:     2010,  Week: 8
   VCP version:         2.2

Display 2
   I2C bus:  /dev/i2c-1
   DRM connector:           card0-DP-2
   EDID synopsis:
      Mfg id:               BNQ - UNK
      Model:                BenQ T2200HD
      Product code:         30502  (0x7726)
      Serial number:        2C803527SL0
      Binary serial number: 21573 (0x00005445)
      Manufacture year:     2008,  Week: 51
   VCP version:         2.0

Display 3
   I2C bus:  /dev/i2c-3
   DRM connector:           card0-DP-3
   EDID synopsis:
      Mfg id:               GSM - Goldstar Company Ltd (LG)
      Model:                LG HDR 4K
      Product code:         30471  (0x7707)
      Serial number:        
      Binary serial number: 86395 (0x0001517b)
      Manufacture year:     2019,  Week: 4
   VCP version:         2.1

[digitaltrails]

The LG is still getting the odd error from time to time when it isn't in power saving.

It might be happening when the desktop is a big bogged down with other stuff. I have a python script that raises selected syslog messages as KDE notifications. At the moment multiple notifications appear to slow the desktop (and also sometimes crash KWin - KDE bug?). Given ddcutil and vdu_controls are both logging to the journal at around the same time, that might be the trigger. In normal circumstances (no errors, less logging) this might not be an issue, but I'll note it here for completeness.

Journal Entry 2023-07-31 13:33:10.741768+12:00

MESSAGE                  : busno=3, sleep-multiplier =  0.30. Testing for supported feature 0x10 returned Error_Info[DDCRC_ALL_RESPONSES_NULL in ddc_write_read_with_retry, causes: DDCRC_NULL_RESPONSE(4)]
PRIORITY                 : 3
SYSLOG_FACILITY          : 1
SYSLOG_IDENTIFIER        : ddcutil
SYSLOG_PID               : 24636
SYSLOG_TIMESTAMP         : Jul 31 13:33:10 
_CMDLINE                 : ddcutil --enable-dynamic-sleep --force --brief getvcp 10 --edid 00ffffffffffff0022f069280101010108140104a53623782efc81a4554d9d25125054210800814081809500a940b300d1c001010101283c80a070b023403020360022602100001a000000fd003b3d185011000a202020202020000000fc004850205a523234770a20202020000000ff00434e5430303831314a360a2020003d
_COMM                    : ddcutil
_EXE                     : /home/michael/bin/ddcutil.latest

[rockowitz]

Hi Michael,

Not sure what to make of your report, but I appreciate your bringing it up. Hard to believe that it's a syslog issue - that's a mature, battle-hardened subsystem. Since only vdu_controls is reading the journalctl output I don't see that it and ddcutil are conflicting. Keep me posted.

On the off-chance there's some interaction between ddcutil's and vdu_control's use of the system log, I've added yet another option that has not yet been pushed to github, --pid/--process-id prepends messages written using syslog with the process id enclosed in curly braces. I believe both programs are executing in the same process, but you may want to check.

There is a very large accumulation of changes that have not yet been pushed to github. I'm still struggling with how to reliably detect dpms sleep mode, display connection/disconnection, and non-standard ways of reporting unsupported features, with variation in monitors, video cards, drivers (Nvidia vs open-source DRM vs non-DRM), display manager (X11 vs Wayland vs none) . Whenever I come up with an algorithm to make a determination, there always seems to be some monitor/video card/driver/display manager combination that breaks the rule. Hopefully things will sort out soon and I'll have something for you to test against.

[digitaltrails]

Hi Michael,

Not sure what to make of your report, but I appreciate your bringing it up. Hard to believe that it's a syslog issue - that's a mature, battle-hardened subsystem. Since only vdu_controls is reading the journalctl output I don't see that it and ddcutil are conflicting. Keep me posted.

It's more that I suspect that KDE's handling of message popups with timeouts is possibly bogging down my system (or at least X-Windows/interrupts/...). So the journal is not the problem. This problem is triggered because I wrote a program to forward selected journal messages as KDE Plasma popups with timeouts (these timeout popups have been buggy/slow/cpu-burning in the past, but I thought they'd got past that).

The takeaway is that sometimes ddcutil might error due to delays from other things going on, possibly delaying handling of messages on i2c.

On the off-chance there's some interaction between ddcutil's and vducontrol's use of the system log, I've added yet another option that has not yet been pushed to github, --pid/--process-id_ prepends messages written using syslog with the process id enclosed in curly braces. I believe both programs are executing in the same process, but you may want to check.

So I don't mean that you needed to specifically address this issue. Just that, more generally, a bogged down system might cause ddcutil issues when trying to talk to a monitor (if timings of responses are important to the exchange).

There is a very large accumulation of changes that have not yet been pushed to github. I'm still struggling with how to reliably detect dpms sleep mode, display connection/disconnection, and non-standard ways of reporting unsupported features, with variation in monitors, video cards, drivers (Nvidia vs open-source DRM vs non-DRM), display manager (X11 vs Wayland vs none) . Whenever I come up with an algorithm to make a determination, there always seems to be some monitor/video card/driver/display manager combination that breaks the rule. Hopefully things will sort out soon and I've something for you to test against.

Generally what's in place now works. When not in dpms, I'm only seeing the odd rare error. Presumably a bad luck timing issue caused by some issue such as I've described above. vdu_controls generally tries a few times and backs off, either giving up or retrying every minute.

If you want to eliminate these normal non-dpms odd-errors, the sleep time might have to hold back a little from the optimum. But perhaps it's the nature of DDC to get the odd error. I may have been getting the odd error before, but because they weren't appearing in the journal, I would not have noticed.

Bottom line:

• When not in dpms sleep, there's nothing to address if the odd error is acceptable/normal.
• When in dpms sleep, monitors behave very differently, so I'm not sure you can reliably deal with that. I guess you might cache some record of what is normal for a given monitor when it is awake, and when you get "abnormal" response assume it is sleeping. For example if a monitor ever properly handles testing for supported/unsupported features, cache that it responds properly, then assume future errors are due to it being in a non-awake state.

[rockowitz]

First, a couple of quick comments on your detailed message:

As DDC communication errors are expected, the extent to which errors are reported in the journal is controlled by syslog level.

Re DPMS sleep, for X11 the check is simple. There's an X11 API call (the equivalent of xset q) to check for sleep mode. In Wayland, it's more complicated. Querying that information for individual displays is non-trivial. For example, KWwin and Gnome each have their code to perform the task. Writing my own code for this would be a non-trivial project.

So for Wayland, or if there's no display manager, and assuming a DRM video driver, I look in syssfs using the individual monitor's connector, e.g. card0-DP-1. For amdgpu, i915, and I assume other DRM video drivers in the open source tree, attribute dpms can be relied on. However, the Nvidia driver does not use this attribute in the same way, so (at least at this point) DPMS detection for does not work in the Nvidia/Wayland or Nvidia/no-display-manager cases. Nor does it work for the various no-display-manager/non-standard-drm cases. But these are rare.

Handling monitor detedtion where the monitor video cable is connected but the monitor's power button is turned off or the monitor is even unplugged is nasty. In general monitors always return the EDID in these cases - the EDID PROM is powered from the cable. However, for some monitors and depending on the plugged-in/power- button-on, plugged-in/power-button-off, and not-plugged-in. the monitor may or may not respond to DDC requests. This complicates (future) hot-plug handling, which is important for the shared library.

I have pushed a large collection of changes that address these and other situations. In particular:

• For testing purposes, --f12 controls whether X11 DPMS checking is enabled. If not, the more complicated non-X11 logic is used.
• Option --fl1 sets a value below which dynamic sleep will not set the sleep-multiplier value. If it proves useful, this will become option --sleep-multiplier-floor. In particular, this is intended to address the jitter where after a string of successes dsa tries setting a lower sleep-multiplier value, causing enough errors for the sleep-multiplier value to jump, only to slowly be adjusted back down again. Unfortunately, there's no universal sleep-multiplier floor value that can be hardcoded - it's monitor dependant.
• --enable-dsa is now a synonym for --enable-dynamic-sleep.
• --discard-cache [capabilities|dsa|all] discards cached data at the start of command execution. There's also command discard [capabilities|dsa|all] cache[s], but unless it is particularly useful it will eliminated in favour of the option.

[digitaltrails]

First, a couple of quick comments on your detailed message:

As DDC communication errors are expected, the extent to which errors are reported in the journal is controlled by syslog level.

What I may do is pass --syslog NEVER unless debug is enabled in vdu_controls.

Re DPMS sleep, for X11 the check is simple. There's an X11 API call (the equivalent of xset q) to check for sleep mode. In Wayland, it's more complicated. Querying that information for individual displays is non-trivial. For example, KWwin and Gnome each have their code to perform the task. Writing my own code for this would be a non-trivial project.

Practically speaking, from the point of view of a vdu_controls user, the only fallout from continuing to issue ddcutil commands when a monitor is asleep/powered-off/unplugged is that extra messages are logged. So disabling logging when no debugging would deal with those.

So for Wayland, or if there's no display manager, and assuming a DRM video driver, I look in syssfs using the individual monitor's connector, e.g. card0-DP-1. For amdgpu, i915, and I assume other DRM video drivers in the open source tree, attribute dpms can be relied on. However, the Nvidia driver does not use this attribute in the same way, so (at least at this point) DPMS detection for does not work in the Nvidia/Wayland or Nvidia/no-display-manager cases. Nor does it work for the various no-display-manager/non-standard-drm cases. But these are rare.

Handling monitor detedtion where the monitor video cable is connected but the monitor's power button is turned off or the monitor is even unplugged is nasty. In general monitors always return the EDID in these cases - the EDID PROM is powered from the cable. However, for some monitors and depending on the plugged-in/power- button-on, plugged-in/power-button-off, and not-plugged-in. the monitor may or may not respond to DDC requests. This complicates (future) hot-plug handling, which is important for the shared library.

Yes, I'm seeing quite varied behaviour from the LG, HP, and Beng. I haven't had any issues raised due these kinds of issues. So correct detection is these situations is a nice to have, but users seem to be coping OK with things the way they are.

I guess errors in these situations raises the dynamic sleep multiplier? I can't say I've been noticed any lack of responsiveness after any monitor dpms or power-off downtime.

I have pushed a large collection of changes that address these and other situations. In particular:

• For testing purposes, --f12 controls whether X11 DPMS checking is enabled. If not, the more complicated non-X11 logic is used.

I'll have a play with it on/off.

• Option --fl1 sets a value below which dynamic sleep will not set the sleep-multiplier value. If it proves useful, this will become option --sleep-multiplier-floor. In particular, this is intended to address the jitter where after a string of successes dsa tries setting a lower sleep-multiplier value, causing enough errors for the sleep-multiplier value to jump, only to slowly be adjusted back down again. Unfortunately, there's no universal sleep-multiplier floor value that can be hardcoded - it's monitor dependant.

This might be a parameter I could use. Currently if dynamic sleep is enabled, I disable passing any vdu_control sleep-multiplier settings. It's possible I could use the existing vdu_controls multipliers setting as a floor. However, on detecting ddcutil 2.0, ignoring the current multipliers has the major advantage than when a user will get improved response without having to change any setting in vdu_controls.

I do have a setting prefer-dynamic-sleep, it's True by default. Currently, if prefer-dynamic-sleep is set to False and a vdu has a non-zero sleep-multiplier, then vdu_controls passes ddcutil --disable-dynamic-sleep --sleep-multiplier val. Instead of disabling dynamic sleep I could pass ddcutil --enable-dynamic-sleep and --fl1 val.

I'd be prepared to accept jitter is the price to pay for faster performance. I've been using ddcutil 2.0-dev as my daily-driver, and it's not causing me any issues. But people who have written ddcutil based scripts might need something like --fl1

• --enable-dsa is now a synonym for --enable-dynamic-sleep.
• --discard-cache [capabilities|dsa|all] discards cached data at the start of command execution. There's also command discard [capabilities|dsa|all] cache[s], but unless it is particularly useful it will eliminated in favour of the option.

Discard cache is going to be handy for testing. Plus it's easier to instruct a user to pass --discard-cache than to describe how to do it manually.

[digitaltrails]

One further note. Would a ddcutil --calibrate command be a way to set a lower bound on dynamic sleep and perhaps also to discover how a monitor responds to feature requests? It would have an advantage of being something that can be run in stable circumstances.

[rockowitz]

I don't quite see what a calibrate command would do that's fundamentally different from the kind of computations that dsa currently performs, checking back over recent operations to pick a multiplier that results in no more than a maximum number of errors or more than a certain average. What I can see is maintaining meta statistics relating to jitter. For example, if reducing the sleep multiplier past a certain level "immediately" causes another change to increase the multiplier value, then that becomes a floor. The problem is that it needs to be a soft floor. Otherwise, over time the minimum sleep-multiplier can only increase.

I've made another small change to the detect command. If dsa is enabled, verbose output reports the current sleep-multiplier.

[digitaltrails]

On Tuesday 08 August 2023, rockowitz wrote:

I don't quite see what a calibrate command would do that's fundamentally different from the kind of computations that dsa currently performs, checking back over recent operations to pick a multiplier that results in no more than a maximum number of errors or more than a certain average. What I can see is maintaining meta statistics relating to jitter. For example, if reducing the sleep multiplier past a certain level "immediately" causes another change to increase the multiplier value, then that becomes a floor. The problem is that it needs to be a soft floor. Otherwise, over time the minimum sleep-multiplier can only increase.

I thought it could be a way of establishing a fixed hard floor, which would then remain constant. But I may not be thinking straight. I think I did a bit much coding today. It seems to be the week where vdu_control users speak up - having been quiet for months.

I've made another small change to the detect command. If dsa is enabled, verbose output reports the current sleep-multiplier.

Thanks for the heads up. I do parse the detect --verbose output, but I don't think extra info will cause any issues (none so far).

Michael