investigate if per process swtcon makes sense

[raisjn]

this task is to run multiple applications using the LD_PRELOAD technique (or other) to get a SWTCON per process and investigate what happens in terms of stability and performance of the display

[raisjn]

one way to do this would be: LD_PRELOAD=./librm2fb.so APP="myapp" remarkable-shutdown. we can then use dlopen() to open myapp binary (which has to be compiled as a shared library) and extract the main() and call it.

the pie flag could be interesting here too (it allows binary to be executable or shared library)

[pgaskin]

To make it more streamlined, if you can make a copy of remarkable-shutdown, you should be able to use DT_NEEDED to have a persistent LD_PRELOAD, and make it so you can symlink the binary to another filename and have it load the filename plus .real (or something like that). This would also give you more flexibility for changes to the shim without breaking compatibility.

[raisjn]

i've been playing around with pausing and resuming processes that use SWTCON and having two of them run at the same time (or even one running, the other paused and then resumed) will cause the state of the display to get messed up.

in specific, one thing that happens is: it seems like the SWTCON loses the knowledge of how to activate pixels if the pixel is not in the state the SWTCON expects. one thing that helps here is flashing a black then white screen and then the SWTCON seems to return to a better state.

i think (big guess here) the SWTCON has knowledge or memory of what is last displayed and uses that to figure out how to drive the display.

[raisjn]

so far, we've decided to go with one server process that does SWTCON stuff