Deprecate and remove Transitions to protect VDU NVRAM

[digitaltrails]

Preset transitions and Auto-Lux interpolation should come with a warning.

[digitaltrails]

Decided to deprecate Preset Transitions. They are now inoperative by default, but can be re enabled by disabling the protect-nvram setting. Preset Transitions are slated for removal in 2.2.0 unless objections are persuasive.

[major-mayer]

I've just seen the pop-up warning for NVRAM protection for the first time, so I decided to disable the transitions and instead use a "stepped" curve that i created manually.

Is profile like this better than one large interpolated section, or did I already add too many steps?

[digitaltrails]

Quoting https://github.com/digitaltrails/vdu_controls/tree/master#does-adjusting-a-vdu-affect-its-lifespan-or-health:

How many writes VDU NVRAM can accommodate is unknown, it is likely to vary by model and vintage. VDUs from past decades are likely to have NVRAM that can accommodate 10,000 to 100,000+ writes depending on the technology employed. For a ten year lifespan this might indicate a sustainable limit of only 2.7 writes per day or 27 writes per day respectively. Some modern types of NVRAM have upper limits that are for practical purposes unlimited, but the level of uptake of such technologies by the manufacturers is unknown (brighter back-lights, along with scene and gaming options, would appear to require increased durability).

I can confirm that a vintage-2010 VDU, which has been used for four years of intensive testing of vdu_controls, now reverts to its factory defaults whenever it loses power. This experience may indicate a write limit of at least 100,000 for a VDU of this vintage. I've subsequently implemented the initialization-preset feature as a replacement for failed NVRAM.

As quoted above, a vintage-2010 VDU seems to be able to sustain at least 100,000 writes. To obtain a ten year lifespan that would indicate 27 writes per day or less. When designing lux-brightness response curves, perhaps try to keep the changes you experience in this range and avoid hundreds or thousands of changes per day.

A modern VDU may have a large amount of USB-drive style NVRAM, potentially it may accommodate more writes. But we don't know, perhaps some manufacturers have decided to be particularly cheap. I would guess VDUs that include volume-controls, gaming/cinema modes, or internal-lux metering, would have to include better NVRAM.

In respect to steps in the curve, note that the default algorithm won't make a change unless it's more than 10%, so even when interpolation is on, the adjustments will still be throttled. I would just keep a rough count of changes and tweek the curves to stay within less than 30 per day, or more if you think your monitors are more modern or up-market.

My current set of curves are similar to those pictured in the README.md, so not particularly finely detailed.

What I'm currently experiencing with an old VDU, an HP ZR24w from 2010, is that outwardly it appears to have a bad-block. At a low rates of writes, the writes mostly work and the settings are properly saved. Every now and then, a setting does not stay set and reverts after DPMS sleep or power-cycling. If I step up my testing and increase the frequency of writes, I can get failures to happen more often. To me, it appears that the VDU is cycling through its NVRAM and sometimes the cycle steps through the bad-block, and at a low rate of writes it cycles through the bad block less often. Now this particular monitor has been absolutely hammered over the past four years because it's the one I use for testing. Having implemented Initialization-Preset, that run at startup and when the monitor wakes up, I'm not no longer affected by the NVRAM problem.

[major-mayer]

Thanks for the extensive and informative answer.
To me, it seems difficult to estimate how many times per day the brightness will be adjusted on average, because my usage pattern is not very similar between days and weeks.
But if you already implemented a feature that will restore the display settings even if the NVRAM is corrupted at some point, I don't worry too much about the consequences of a failure, especially since my secondary display is already quite ancient.

I now decided that I keep my curves as they are but decreased the adjustment frequency to every 20 minutes. I think this should be enough to handle most situations.

[digitaltrails]

Thanks for the extensive and informative answer. To me, it seems difficult to estimate how many times per day the brightness will be adjusted on average, because my usage pattern is not very similar between days and weeks.

I've added internal counters to v2.1.1 that count the writes made to each VDU during the current execution. The current values are displayed on the bottom of the About-Window whenever it is brought up. So, for example, if you start vdu_controls at the start of the day, bring up the About-Window window at the end of the day will reveal the day's total, which would allow you to judge whether this is acceptable.

But if you already implemented a feature that will restore the display settings even if the NVRAM is corrupted at some point, I don't worry too much about the consequences of a failure, especially since my secondary display is already quite ancient.

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 now decided that I keep my curves as they are but decreased the adjustment frequency to every 20 minutes. I think this should be enough to handle most situations.

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.

[major-mayer]

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.

[digitaltrails]

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.

What I have attempted to do for my own VDUs is to identity a level for sunny, overcast, dark-rainy-day, eventing and night. So I don't vary infinitely, just between a few levels.

I've attempted to set a conservative kick in for overcast to stop moving clouds from flip flopping the brightness, but still sometimes have to switch to manual when light levels are very changeable, which is not often.

In my case I've assign these levels to Presets and the Presets are attached to the lux-curve. This is mainly because I coded Presets before I coded lux-metering. (If I had got out a soldering iron a year or two earlier, I think I could have avoided coding a lot of features which I now don't use - such as all the solar elevation and weather stuff.)

I think you should try what pleases you, and if the write count is low, don't worry too much. I've just fixed the write count (it was erroneously counting attempts to change the VDUs when they were offline/asleep).

[major-mayer]

Ahh I see, that also explains why you have put so much effort into this whole presets thing, something that I haven't used yet.
For me, the lux metering thing works just perfectly, especially now with the self-made lux sensor instead of the webcam :)

I'll keep the write count on my radar. Thanks again for your great work and the effort in general that you put into this project.