[linuxkerneldev]

For those feeling the impulse to empty their wallets, I urge caution. I just got done being burned by the kickstarter for the goodreader equivalent. https://www.indiegogo.com/projects/13-3-inch-android-e-reade...

I see no evidence that the team behind this "remarkable" product has ever completed anything of this scale.

Some of the claims are very suspicious. https://liliputing.com/2016/11/remarkable-10-3-inch-writing-...

"reMarkable says the screen has 55ms latency for quick response from pen input"

55ms would be impressive for an LCD. Even the iPad Pro has a latency of 60ms [1]. So a 55ms claim for an E Ink panel? Should raise one's alarm detector.

[1] http://www.anandtech.com/show/9766/the-apple-ipad-pro-review...

[bravo22]

I'll bite... their claim of 55ms is most likely for a tiny region to be updated. It is not for the whole screen. You'll notice in their video that full page updates are still slow.

I've worked w/ e-ink technology and designed similar hardware before. Here is how they work:

You scan across the matrix, setting the row/column multiplexer to the dots you want and flip the dots between black and white as needed. This flip is a physical process and has an inherent latency. You can't move to the next pixel until you've finished flipping this one.

The flipping process is basically applying a high positive or negative voltage to the tiny plate under the pixel, which causes either the positive or negative side (black or white) of the embedded dot to show. The amount of voltage you apply determines the intensity. If you want crisp edges and accurate shades of gray then the voltage also depends on manufacturing characteristics of that specific panel. E-Ink actually gives you a waveform for each panel they hip, and that waveform is also temperature dependant -- because the liquid the dots are suspended in changes viscosity based on temp.

So you can do a bit of simple calculation and determine the voltage to go from say 25% gray to 55% gray. This is faster because normally you'd go to either black or white and then to your target shade. This is why you see that screen "flashing" when there is a full page change.

To bring it all back... if you only need to update a small region, say the area around the tip of the pixel, you can do so relatively quickly -- compared to the whole screen -- hence their 55ms claim.

Personally, I noticed a fair bit of latency in their video.

As an experiment for a previous project we rolled our own FPGA based driver and were able to get small region update down to about 20ms.

[linuxkerneldev]

> we rolled our own FPGA based driver and were able to get small region update down to about 20ms.

That is very impressive. 20ms latency from the time a pen hits the display to the point that a pixel is drawn on an EPD is twice as fast as an iPad Pro is able to do it on an LCD! Any links to your project?

[bravo22]

This wasn't pen to screen update. The driver was only for screen update. It wasn't an open source project. It was work-for-hire.

[sandsmark]

the latency is basically the only thing we've focused on for a while, it's a very focused device in terms of what we spend our resources on.

the high latency is one of the reasons normal tablets suck for writing and sketching.

[RandomOpinion]

>For those feeling the impulse to empty their wallets, I urge caution. I just got done being burned by the kickstarter for the goodreader equivalent.

What's the "burned" part about? I'm reviewing their updates and everything seems normal.

[cordite]

Similar stuff is going on for other e-ink stuff, like Popslate. It's facing considerable delays despite having a physical hardware prototype.

Currently they are struggling with certified for iphone.

[cokernel]

Could you clarify the source of the 60ms figure for the iPad Pro? The review you cite says:

> After a few trials I measured an approximate latency for the iPad Pro of roughly 49ms or 3 frames of delay

[douche]

I'm holding out hope, but the endless cycle of delays does not look good with the goodreader project...

[squeaky-clean]

> After a few trials I measured an approximate latency for the iPad Pro of roughly 49ms or 3 frames of delay,

From your linked article, the iPad is faster than you say. This is also in the Photoshop Sketch app. It's faster in other apps.

> To give an idea for how much the application has an effect on latency, the Apple Notes app has roughly 38 ms or around 2 frames of latency from when the stylus tip passes over one point to when the inking reaches the same point.

[kod]

the same article you linked states that sofware is a major factor in lag, because a different app has ony a 2 frame latency.

[CoolGuySteve]

At 55ms I'd much rather have a phone or netbook with this display. So I'll believe it when I see it.

[mercury888]

can you tell me how you got burned by that indiegogo campaign? Did you back the product and receive it?

[scottlocklin]

They're just reusing the hardware module Sony uses on its Digital Paper DPTS1 thingee and putting Android on it. Assuming it's a legit project.

[sandsmark]

no, we don't use Android, unlike pretty much everyone else.

and the EPD is designed by e ink based on our requirements, e. g. the size and high DPI.

[linuxkerneldev]

> no, we don't use Android, unlike pretty much everyone else.

Most companies making EPD products use the base OS provided by their SoC vendor. Based on your spec which says 1GHz ARM A9 , I'm guessing you're using the NXP (formerly Freescale, now Qualcomm) i.mx6 SoloLite since that's the only 1GHz ARM A9 with an EPDC controller on the market. Freescale gives you a Linux EPD and an Android EPD Linux BSP, both of which use the same epdc driver with pretty much the same latency which is definitely pretty high, much higher than 55ms for sure.

> EPD is designed by e ink based on our requirements, e. g. the size and high DPI

Are you claiming that E Ink manufactured a custom 10.3" panel just for you?

[sandsmark]

Again, I can't discuss too many technical details. But yes, it's an i.MX6SL, I thought we mentioned that on the web page.

And there are actually several drivers for the EPDC available. Two from freescale for the imx6 and imx7 (though there are some other improvements in the _v2, apart from imx7 support). There's also another one written by lab126, but I'm not sure if they actually use it. there's also some minor variations in the drivers in the different kernel branches and trees from NXP. And then you have the u-boot drivers. And I think there might be one in the bare metal SDK, but I haven't looked. And then you have the 5bit waveform support, which is a whole other story (with iffy GPL implications for some vendors I won't name).

And the display was designed based on our requirements, but we don't have any kind of exclusivity on it. there's already other devices coming out with it (you can find them if you google the specs, especially the awkward resolution we got thanks to the limits of the technology and our DPI requirement).

[linuxkerneldev]

> it's an i.MX6SL, I thought we mentioned that on the web page.

Your website only says: "Processor 1 GHz ARM A9 CPU"

> Two from freescale for the imx6 and imx7

Ok, but you are using imx6.

> There's also another one written by lab126

Nope. That's the same driver from Freescale. You can download the kindle source to verify. https://www.amazon.com/gp/help/customer/display.html?nodeId=...

> then you have the u-boot drivers.

u-boot just draws a splash screen.

> you have the 5bit waveform support, which is a whole other story (with iffy GPL implications for some vendors I won't name).

I don't understand what you're trying to communicate. Why would a EPD waveform have any GPL implications? An EPD waveform is not software, it is a set of timing values and that's it.

> the display was designed based on our requirements

I'm having difficulty understanding what that means. It sounded like you were saying E Ink designed a panel for you, but maybe what you're saying is just that E Ink had a panel that met your requirements.

[sandsmark]

there are two epdc drivers in the kindle gpl releases. the source for the lab126 one is only available in the tarballs you linked (named mxc_epdc_fb_lab126.c).

as for the waveforms, I'm talking about support for the REAGL (sic) waveforms. grep for it in the linux source in the tarballs you linked to.

and e ink did not have a panel that met our requirements, and designed a new one after we talked with them.

edit; just to be clear, we don't use the lab126 driver, it was just an example of there being more drivers for the imx6 generation epdc.

[baggers]

The goodereader 13" is android, ReMarkable isn't. And the gooderader project has not turned to vapour yet althought I can understand linuxkerneldev's reason for being annoyed.