Worrying about this is the main reason we don't ship DDC/CI with f.lux. (I know that some more modern monitors use NAND and don't have limitations like this.) Anyone know if these fears are overblown?
For things like setting brightness or toggling devices that ought to be dead simple, stuff like DDC/CI and HDMI-CEC being broken on so many levels never fails to make me spectacularly sad.
Use DDC/CI, and they'll stop. Even NAND is wrong if brightness is actually dynamically controlled, it should just be RAM.
Such monitor recommendations could only be based on people tearing down things, which is outside the scope of Lunar and f.lux.
There is never a guarantee that you don't get stuck with a dud monitor, in any aspect. However, companies making products with bad reliability is going to face high support/warranty fulfillment costs and get a bad reputation. And if it fails within warranty/consumer protection periods, you lose nothing.
So, write away, and flood bad manufacturers in complaints. It's all you can do as a consumer - the alternative boing to get AMD, nVidia or Intel (or Displayport/HDMI interest forums) to be interested in making requirements against display manufacturers on the matter.
BTW, assuming I change brightness 20 times per day, that would still give me 5000 days ≈ 13,5 years of service. By that time I definitely hope to use a different monitor than today
So every time you write to three same byte you're writing the same cell. 100.000 cycles is actually much more than current flash generations.
Early EEPROM could only be wiped entirely (but as this was done electrically, it was still an improvement over UV-erased EPROM), while EEPROM at the time of Flash's creation could often be byte-erased (as is the case now).
Nowadays "EEPROM" mostly refers to small, slow, rarely written config storage for microcontrollers. As thus, they are also usually accompanied by low write/erase endurance despite their byte-erase granularity.
Flash was meant as a higher capacity/performance version indeed sporting full block erasure as a downside, but nowadays it has supplanted EEPROM in all categories but small micro-controller usages. Plus, as capacity is now cheap, high write loads can easily be supported with write levelling (that is, writing to new locations instead of erasing/writing the same block over an over.)
100,000 is a typical eeprom guaranteed write count. It will likely last much longer. The eeprom is probably much bigger than they need for such an application so they could actually handle the wear case by moving to alternate locations when write failures occur.
This is not an option when using DDC/CI, where each brightness change is an isolated command. Plus, the OS is likely to emulate a smooth transition by sending even more commands than the end-user dictated.
Sure, the firmware could defer storing to EEPROM until a timeout from last command, but I would not credit the average display firmware as being that thoughtful.
> 100,000 is a typical eeprom guaranteed write count.
No, it's usually an estimated write endurance at a certain voltage and at 25°C, with the number based on calculated risk of failure being lower than a non-zero threshold. Higher temperature and voltage leads to higher failure rates.
I have dealt with several EEPROMs dying after just thousands of writes, including ones in products manufactured at a previous employer (where the EEPROMs were replaced with modern flash). Reserve EEPROMs for when writes are the exception.
Seems like the kind of thing you could easily test if so inclined and properly insured?