91–100 of 105 posts
And still has zero actual videos of the device in action, which makes it really hard to get excited about it rather than cautiously apprehensive. $400 might be cheap compared to, say, a remarkable2, but not if the display turns out to be flat-out mediocre. Then that's $400 better spent on "saving up for a remarkable2".
https://twitter.com/thepine64
It’s worth noting that this is a bit more powerful than Pine64’s other hardware releases, in part because it’s using the same base chipset as its Quartz64 SBC, released earlier this year: https://wiki.pine64.org/wiki/Quartz64
I wouldn't call this more powerful than pine's rk3399 products. It's a bit less powerful than that. Though I've just started playing with my quartz64.
Earlier quoted context omitted.
If this e-ink device is usable as a secondary display for my laptop, I'm in. I'd love to get work done in sunny locations, like gardens. But these LCD screens make me squint. e-ink would be THE solution to this, but the e-ink displays are too expensive, to well supported and not very big.
There is a community VNC client for it. If you're on Windows you'll need a HDMI dummy plug to simulate a second screen with the proper dimensions. But yes, it works as an external screen. Check out VNSee for this https://github.com/matteodelabre/vnsee Maybe the rM1 might be the best choice for this. I'm not sure...
The rM2 is a lot trickier. A full reverse engineering of the drawing routines is still unfinished, as far as I know. So you either manipulate the memory of their closed source application or reuse big binary chunks of it. There are of course abstraction layers built over that by the community but as of today I believe it's much less refreshing than the rM1.
The rM1 used the chip electrophoretic display controller directly , while the rM2 has a software controller which is closed source. Hence much of the complications
Earlier quoted context omitted.
Actually, it's better than you describe it, I think. Most components are FOSS. The default GUI and the framebuffer driver are proprietary closed source. However, the framebuffer driver has been extracted from the GUI service by github user ddvk and faciliates the development of independent interfaces (look for "launchers") that can launch further independent programs, e.g. harmony https://rmkit.dev/apps/harmony There…
> 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 w…
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.
Earlier quoted context omitted.
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 :/.
I'm still very happy with the device but I'll keep that in mind when recommending it to others.
Earlier quoted context omitted.
> 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 w…
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…
Earlier quoted context omitted.
> $400 might be cheap compared to, say, a remarkable2 A reMarkable 2 costs $399 brand new, so I'm not sure what you're on about.
Sure, and then you don't have a pen or a case. So that's not what it actually costs.
Earlier quoted context omitted.
What about a normal book light that you’d use with a traditional book? I find that even the Kindle light can be uncomfortable when in complete darkness, so I try to always keep a little bit of ambient light, which is usually enough to read by.
I use a book light with my Remarkable. It works well, but I'd still prefer an integrated frontlight, as long as it didn't affect the writing experience.