Burn in?

[gdkrmr]

I am developing the partial refresh 4.2 inch driver and during development I always use htop for testing and sometimes I just leave the display running for an hour or two. Now I can see the htop layout every time my screen does a refresh. After doing constant refreshes for 5 minutes, the `htop screen has faded a bit on displayed images, but is still very much noticeable during refreshes.

I guess terminals are the worst case scenario for burn ins, because they have characters always at the same positions.

Anyone else with this problem? Is this going to be permanent? Do we need a random frame buffer for refreshing or random shifts (like OLED displays) to avoid this?

[joukos]

Hmm, well in the end the display has the stuff floating around and with my not-entirely-working 2.13" display I need to use the scrub procedure to sort of "degauss" it and clear the image properly so it's clean again. I think I had some other problems when experimenting with partial refresh and the 4.2" and seem to remember vaguely that there might have been some ghosting that was fixed eventually by doing enough refreshes (or perhaps filling the screen first). (This comment is related https://github.com/joukos/PaperTTY/issues/15#issuecomment-420390546)

I think we ought to add a configurable full refresh interval for the terminal mode too to try to keep the image clean, at least.

[gdkrmr]

What I don't understand is that I can make the whole image white, but during scrubs, I can see the htop pattern, even if the image is totally unrelated, as if there was some kind of global memory or as if the pixels that have been switched too often would simply behave differently. Maybe the black and white particles get "mixed" up inside the pixels if there are too many switches and have to be separated properly by turning everything black/white a couple of times.

[joukos]

I had the same happen with at least the 2.13" (IIRC) - I think it just had to do with not updating the memory pages correctly, ie. leaving part of the memory untouched when doing an update for whatever reason (such as something in the code messing up). I don't now recall the specifics of partial refresh for the 4.2" but I think it's likely that there's something similar going on, or at least something fixable.

If I remember correctly, in the case of 2.13" there are two memory pages on the device and with partial refresh two write operations are done, the display itself will switch the page it's writing to when the command is issued again. If the other is not updated, there will be a blinking ghost image of something when a refresh is done, or you perhaps see the stuff you want to display blinking for a while but it will end up blank in the end.

Maybe try to disconnect it completely for a while and try to draw something on it again using full refreshes (and non-experimental code), I think it's unlikely that such a condition is permanent and I've had it happen too. I think I actually left the unit for a couple of days disconnected and then at least it worked fine again.

[joukos]

Sort of related issue I just added: https://github.com/joukos/PaperTTY/issues/48

[gdkrmr]

in terminal it is probable that there are some unused pixels at the borders, because the height and width of a character do not divide the number of pixels of the display. We could implement a slight random shift within these unused pixels to avoid burn in. I think this is how OLED displays avoid the issue.

[joukos]

I think I'll close this as there's nothing to add right now - maybe a more specific issue can be opened if there's still problems with this, or some ideas about it.