> However, the framebuffer driver has been extracted from the GUI service
Extracted? Last time I look at it, they were inserting a patch in the main (and only) binary of the proprietary GUI via LD_PRELOAD, and then all other programs which wanted to draw _anything_ to the screen would basically _directly alter the memory_ of the proprietary GUI binary in order to modify its internal framebuffer. You have to do that whether you want to integrate with the main GUI or not -- since you need this hack to draw anything to the screen.
Literally every other Remarkable update so far has killed all of this.
> Most components are FOSS.
The usual thing: most 3rd party components which they are forced to open anyway are FOSS. Anything that may even be remotely interesting is NOT FOSS. I do not understand why people try to claim this as a positive, cause it isn't.
I wouldn't look at the mouth of a gifted horse. Their closed source binary is not huge.
Also I don't worry about updates. Why would I connect my notebook to the Internet anyway? I just don't install them.
I guess it's a matter of time before fully open source display drivers are available and I can do my part too to make it happen.
When it happens I will have an ownable very nice, thin and responsible e-notebook. It will never be connected to the Internet and I will patch it myself if I will happen to want a new feature.
Maybe you are right and it could be more FOSS than it is, but in a world where you don't really own anything valuable anymore I am so elated about the hackability of this device that I'll take a bit of tinkering with binary files.
xochitl (the rM GUI) doesn't need to be run when other GUI programs are running. I don't fully understand the way this works but for anyone interested, here is the link for the framebuffer workaround: https://github.com/ddvk/remarkable2-framebuffer
On rM1 it was possible to write to the framebuffer directly, on rM2 it is not exposed as a device file directly.
The link you are sharing explicitly mentions you need xochitl running with the LD_PRELOAD hack, which is what becomes "the framebuffer server". In fact,
> To do their job, both the client and the server need to know the address at which a number of functions reside in the Xochitl binary. These addresses change from one release to the next.
This is absurdly fragile. In fact, it's even worse than I was guessing :/.
Extracted? Last time I look at it, they were inserting a patch in the main (and only) binary of the proprietary GUI via LD_PRELOAD, and then all other programs which wanted to draw _anything_ to the screen would basically _directly alter the memory_ of the proprietary GUI binary in order to modify its internal framebuffer. You have to do that whether you want to integrate with the main GUI or not -- since you need this hack to draw anything to the screen.
Literally every other Remarkable update so far has killed all of this.
> Most components are FOSS.
The usual thing: most 3rd party components which they are forced to open anyway are FOSS. Anything that may even be remotely interesting is NOT FOSS. I do not understand why people try to claim this as a positive, cause it isn't.