Is there a way to know how my monitor does this?

Either disassemble your monitor and lookup the ICs, find someone who already did it, or try to write about 100 000 times and see what happens... :)

Fair. I was hoping there was a list of common or known monitors that do this.

You could pay to buy monitors for people and ask them to toggle the brightness until it dies, then record it down on a wiki and opensource this information.

Or there could just be some part numbers that indicate a monitor has this issue

I've been reading that NAND flash doesn't support erasing individual bytes, while EEPROM does. If there's some way to attempt this and know the outcome, maybe that's a way to figure it out.

NAND Flash is just a type of EEPROM.

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.)

The problem is that eeproms don't do wear leveling. Not internally and they're usually controlled by a simpler microcontroller that doesn't have enough resources to do it in software.

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.

These days basically every kind of mass storage device you will use has its own dedicated controller chip which is pretty much a cpu with its own RTOS now. Those 2 cent 8kb eeprom ICs don't but its crazy how complex something like an sd card is.

Some of those SD cards run linux! https://hackaday.com/2016/06/30/transcend-wifi-sd-card-is-a-...

Yea, I'd really prefer to not brick two expensive monitors because of this. This thread has bummed me out.

I'd like to know this too!

Hmmm. I hope the firmware authors weren't that dense. I would imagine they do a write when you exit the brightness change menu.

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.

> Hmmm. I hope the firmware authors weren't that dense. I would imagine they do a write when you exit the brightness change menu.

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.