I've added internal counters to v2.1.1 that count the writes made to each VDU during the current execution.

That's fantastic, I am sure it will help a lot.

The main limitation with the fallback is that it is limited to the DDC VCP features exposed by the VDU, so it can't necessarily restore everything. The fallback works best when using the DBUS ddcutil-service because that detects VDUs waking-up or being powered-on which can then trigger the restore.

I see. I am using the DBUS service anyway, but yeah, if there are some features missing that would be unfortunate. A bit more transparency from the vendors about the used NVRAM would be very helpful.

If the total count reported in the About-Window is <30 writes per day, that likely result in a long lifespan. That's a conservative value, a newer VDU may well allow for more than that.

Sounds good.
But if I turn down the adjustment frequency to such a conservative value, can I enable interpolation again? If I understand it correctly, the number of adjustments should still be the same, just that the curve is smoothed then, right?
At least from quick testing, this seems to be the case. So even if there is and abrupt change in brightness, the VDU settings won't be adjusted until the next 20-minute window is reached:

Edit: Now that I think more about it, this assumption is wrong, because while there might not be a change within the (in my case) 20-minutes windows, there are now potentially more changes, after a 20-minute window is finished, because of the many interpolated values, vs a few bigger brightness steps/ classes.

Deprecate and remove Transitions to protect VDU NVRAM #93

Description

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions