Show HN: A VNC viewer for eInk devices capable of 30 FPS when writing text | Hacker News Reader

Show HN: A VNC viewer for eInk devices capable of 30 FPS when writing text

github.com

303 points_8rlb96 comments

For people who cannot visit the website (hug of death), a copy is hosted here: https://github.com/everydayanchovies/eink-vnc

This is great, looks totally usable.

I've pursued that eInk life style for about a decade now :) My best setup is with a Dasung Paperlike, but in practice the ergonomics keeps me from using it often (too many things to carry outside and setup). What I hope to see one day is a Linux friendly laptop with an eInk display (frontlit for extra bonus [1]). I wouldn't use it as a replacement, but for quickly grabbing when spending a few hours outside. Maybe Framework or MNT Reform could do it?

[1] the Dasung has multiple settings for the backlight and it's an absolute necessity for using it indoors.

EDIT: backlit -> frontlit, silly me.

ADD: PineNote is also promising as it support BLE and thus could be used with remote keyboard/mouse.

Maybe you’re aware but the Boox Max Lumi has an HDMI In port, so you can use it as a secondary monitor for that laptop.

https://shop.boox.com/products/maxlumi

My Dasung Paperlike is a monitor also. In practice it's not a great solution for me compared to laptop (self-contained, batteries included). An external monitor (incl. the Boox) is quite impractical to lug around and set up.

The boox refresh rate is not adequate for anything besides regional (text) updates. I have used the max, max2 and the mira and they have all been pisspoor for anything besides wordprocessing. VNC and RDP have mostly been better as these protocols understand regional changes more than the Toshiba HDMI converter chip they use.

That is very interesting! Thanks for that info.

Reminder: onyx violates the Linux kernel license.

https://old.reddit.com/r/Onyx_Boox/comments/hk7d5v/onyx_is_v...

This may be interesting for you: https://www.modos.tech/

I just heard about them recently and am curious how the final result will look like.

Le voila !

Thanks, that could be just the thing.

Looks pretty cool! And soo smooth.

Wow, this is great! I've been hoping for eInk with good refresh for years, and seeing it in action in your demo is very cool.

> The screen can refresh up to 30 times per second, this will degrade the eInk display rapidly. Do not use with fast changing content like videos.

Have you noticed the degraded display in your Kobo? I imagine it's not uniform across all pixels, since editing would mostly be localized to your cursor area (though scrolling and other actions would be wider). I'd also be interested in hearing what the timeline looked like for the quality drop, since it sounds like it's a function of the total number refreshes for each pixel.

Thank you :)

I haven't noticed any degradation, but I put the warning up just in case. There is research suggesting that the ink "drops" stick together or break up after so many refreshes.

You can quickly skim this page for more info (the title should be findable on libgen): sciencedirect.com/science/article/pii/S0030399217315487

I thought 11 years ago that e-ink with good refresh was achieved, seeing bookeen's prototype display videos and full screen scrolling.

https://www.youtube.com/watch?v=24srQXX81Oc https://www.youtube.com/watch?v=CxwceUvxlCo

But all e-ink devices I have seen since were slow and would form time to time show remanence.

A comment in the video says that the framerate is being held back primarily by network latency. Would something like mosh, which immediately updates local state based on how it thinks your input will change the state (and then applies any necessary corrections once the network round trip happens) help here? I guess it would only apply to text-based sessions, but it sounds like there's already a recommendation against using it for video content.

One of these days I'm gonna make something this cool I can show HN.

I'm trying to get xdebug working on AWS ECS... do you think that will qualify?

This shouldn’t be the goal

Try to solve the world climate and energy problems first

Show HN: I solved the world climate and energy problems

An interesting test case would be the aalib demo, bb:

https://sarata.com/manpages/bb.1.html

Here videoed off an emissive display: https://yewtu.be/watch?v=WubDqdV2r9k

And what seems to be a direct screen capture: https://yewtu.be/watch?v=JFFJYJ6QkME

I'm also curious as to what display damage high-speed refresh causes, and what reasonable guidelines at avoiding this might be. I have an Onyx BOOX Max Lumi, whose display is excellent, and do very occasionally watch video. (More often I'll simply play the audio via mpv in Termux.)

The pixels are classical mechanical, as opposed to LEDs (electrical) or other solid state devices.

The particles in a pixel could deform/burst or clamp together over time, as they move around. Both scenarios lead to decreased contrast.

The less they move the longer the screen will last. I've no experience with the manufacture of those displays but I reason with physics.

More fluid than mechanical.

Note that even electrical displays can suffer burn-in, with CRT, LCD, and LED screens all exhibiting this. (I'm unsure about plasma displays, as I don't understand that technology.)

Yes! But intuition tells me that suspended particles moving past each other make a more fragile system than solid state devices.

Also take into account the difference in refreshes between reading a book (0.05 HZ) and writing (30 HZ). That is, using the display as a general purpose monitor necessitates 600 times as many partial refreshes. I approximate full screen refreshes occur 6000 times more often.

If degradation goes linearly with usage then the lifespan of the display would decrease significantly if used as a monitor. It would be good if someone in the industry could comment on this.

Exactly what I've been wanting to do, use it as a display for emacs with a bluetooth keyboard. Don't mind if it has to pass through my laptop. Does anyone know how to do something similar with the reMarkable 2?

I did this once, with a shared terminal via screen or tmux (and thus not VNC). You can install https://github.com/Eeems-Org/oxide and a terminal application via the toltec repoitories and then ssh (or mosh) from remarkable to the device that has the keyboard.

There's https://github.com/matteodelabre/vnsee if you want to use VNC as a client on your remarkable. I've used it in the past to run Chromium on a server and display it on the reMarkable: https://photos.app.goo.gl/TnNE1tdzvrwphJ8N6

What are the current market options for e-ink /displays/devices that you could program on/ that you know of and (don't?) recommend ?

Here's my notes on the subject:

    - hisense q5 tablet
      - hdmi input
      - https://www.cect-shop.com/en/hisense-q5.html
      - 400 eur
      - android as usb display:
        - https://superdisplay.app/
    - waveshare
      - https://www.waveshare.com/product/displays/e-paper/epaper-1.htm?___SID=U&dir=desc&mode=list&order=price
      - pure hdmi, usb powered
      - 400-600eur
      - papertty
        - python library
        - streams terminal or vnc to raspberry pi connected SPI waveshare monitor

I got a Boox note air 2. It's an e-ink device/android tablet/e-reader/note-taking.

You can install any app on this device. I find it's acceptable to code with web-ides like replit.com. But my main usage is reading and note taking.

I personally use a Remarkable 1 with yaft (1) as a terminal. I connect via ssh to a tmux session for editing and the response is fast enough.

1. https://github.com/timower/rM2-stuff/tree/master/apps/yaft

Don't let the .cpp file extensions fool you, its c.

I’m doing the same, though I had to fork Yaft to get a bigger font.

Do you mind sharing your fork with the font change? I tried to get a font that supports other characters but the mkfont_bdf tool didn't like the files I fed it.

Here's a font that worked for me: ```curl -Lo spleen-16x32.bdf.bdf https://raw.githubusercontent.com/fcambus/spleen/master/sple...```

Added a Dockerfile to make the build easier here: https://github.com/DaveHarrington/rM2-stuff

There is the PineNote [1], don't have one but do have the equivalent SBC.

[1] https://www.pine64.org/pinenote/

Oh, this is great. I love my Kobo Libra 2 mostly due to its form factor and weight and have been thinking of using it for something more. Hard to believe the thing can do full scan text refresh 30 at fps, though. Probably not updating everything at once?

Also, I did not know eink degradation due to normal use - as opposed to sitting on your beloved device :( - was a thing, even at high fps.

The degradation is speculation on my part. I haven't ever experienced it.

Yes, the 30 fps rate is for small updates. A full screen update (scrolling) is commonly less than ~200 ms, and there are still ways to bring that number down.

I agree, the Libra 2 is great :) Try koreader, it's noticeably faster than the stock reader application.

I'm so excited for this: https://www.kickstarter.com/projects/bigme/bigme-worlds-firs...

Basic color support for syntax highlighting is what I've been waiting for...

It looks interesting, is there some information that describes whether this runs an upstream Linux kernel without version-locked binary blobs?

It says it runs Android, and thus the above makes the difference on whether I one rely on 2 years of updates or 20 years of updates.

Impressive! Just wondering, can this work with ssh? Using VNC for text based application sounds a bit overkill.

I'd love to see someone crack the partial fast update modes of the Boox tablets.

They run Android apps, but only the included, closed-source apps like the note-taking app and browser get fast screen updates at high quality. If you try to install a third-party note-taking app the experience is crap.

Can you not use ADB to download the APK off the app and reverse engineer anything anomalous?

Maybe the apps are completely normal, but whitelisted somewhere in the system for different behaviour. Like some phone manufacturers cheat at benchmarks...

I don't think that's it. The issue is how to tell the screen to do a fast partial refresh at the expense of not refreshing anything else, which is what you want for handwriting. The app would need a way to tell the system what to partially refresh, i.e. some sort of nonstandard Android API.

The Boox tablets are touted for their ability to run third-party Android apps, so I highly doubt they would deliberately cripple them.

Check out what Zubersoft has done with their sheet music app, in a special edition for e-ink.

https://zubersoft.com/mobilesheets/forum/archive/index.php?t...

The kicker is this: “- Freeform annotations with the stylus utilize special rendering on Boox devices allowing the drawings to show up in real time. This makes it much easier to write and draw.”

I use this app on a Boox Max Lumi and the effect is very pronounced. It really doesn’t have any noticeable delay, just like the “native” Boox apps.

So, I think someone did indeed crack the code for fast updating.

Oh damn! Thanks!

I've been using my Remarkable 2 as a terminal for Vim via SSH. Works a treat - like having a super capable typewriter: https://imgur.com/a/hyLjg14

How are you SSHing out on the Remarkable? I would be interested in picking one up for this use case.

Do you mean "how am I SSHing to the remarkable"? That's pretty straightforward - follow https://remarkablewiki.com/tech/ssh. I'm just doing it from my laptop. You don't have to SSH though, you can plug a keyboard in as well but that's a little more involved.

Oh I thought you were SSHing to your laptop / server from the Remarkable.

Yeah, you could if you plug a keyboard into the remarkable as it’s just running Linux. The plug position is a bit awkward though.

Does somebody know, is there similar thing for recent kindle paperwhite? I tried to google, but too many false positives...

I basically want to start a ssh client on kindle to use as a display for my laptop/steamdeck (via tmux ofc)

A while ago, I made a similar tool for Pocketbook eInk readers specifically: https://github.com/borzunov/remoteink

I appreciate the effort and novelty that goes into things like this, but I would never, ever use such a thing. Sure I have a kindle that I read on, but I'll keep my 27" 5k screen for coding thanks.

I wanted to give it a try since I have a Kobo laying around but seems like TightVNC is Windows-only.

It's in nixpkgs (for MacOS and Linux). I haven't tested it because it's flagged as having a security vulnerability (actually that's an excuse - it's really because I'm busy) but it should work.

It is on ubuntu, for sure.

Is the notable delay between keyboard sounds and video rendering due to the SSH/software?

Later he writes a comment saying is due to network latency. Seems a bit dubious if you ask me though.

Seems legit to me.

Using an Onyx BOOX with Termux, terminal lag is not perceptible. The lagged updates look like packet jitter to me.

Could be the classic nagle / delayed ack interaction. Or shoddy wifi.

I measured and split the latency between the main tasks of a single frame draw.

The main culprit was network delay as I am transmitting raw pixels (one u8 per pixel) compressed with zlib. That's a hit of ~140ms for half a screen.

Next in line is the screen refresh (unmeasured, perceived).

Then the optional post processing (~20ms for half a screen), and housekeeping, like keeping track of dirty regions (about as long).

Lastly writing to the framebuffer (less than 20ms, I don't remember exactly how long).

I took great care to optimise the process, and my next step was to transmit multiple pixels as a single u8 int, the physical display cannot render 255 distinct shades of gray.

P.S. parent was right in doubting the claim, as a parallel connection from a client on a regular desktop refreshes at 30 HZ regardless of the size of the update.

The explanation is that I take end-to-end network measurements (from request of update to a full buffer of pixel bytes). That delay might be due to the slow processor on device, or an inefficiency in the networking code in my application.

Interesting. But updating one character should be much faster than updating the whole screen then surely since you don't have to send so much data?

By the way I suspect compressing multiple pixels into one is unnecessary - just quantise them and let the compression deal with it.

Also zlib is not designed for image compression. I'm sure there is something more suitable, e.g. QOI.

In fact, given that you're mostly compressing mono text I wouldn't be surprised if some kind of dynamic sprite atlas kind of system was better, like in JBIG2.

Anyway if it is network latency that seems like good news because you should be able to get it to near 0. What is the ping to the reader?

Apologies for the late reply @IshKebab, I read into your recommendations and they are very interesting.

If you wish you could copy your comment verbatim as an issue over here, so we can discuss it further: https://github.com/everydayanchovies/eink-vnc/issues

I will have a chance to test the ping tonight, possibly.

Nice work. I'd really miss colours though, e.g. code linting and bracket colouring

There is a lot of room to play with there, I code monochrome on colour displays too.

Try experimenting with font weight, italics, and combinations. I find that less distracting.

Nice. I wish I could put this on my Kindle

What is your use case?

I don't know.. But I have several old kindles laying around :)

Would be a nice console or something.

In fact I'd love a laptop with eInk which I could use outdoors in the sun.

Imagine where electronic ink displays could be today if E Ink wasn't such a terrible steward of the initial technology.

I'd say you might get your wish in about five years, after present patents expire. There will doubtless be new developments, but present devices are absolutely sufficient for e-book reading and most web surfing / tablet tasks, even at monochrome and modest 0.5 -- 16 Hz refresh or so. Higher-quality display is slower to refresh, though almost all instances are well under sub-second.

Colour displays are slower as I understand.

We really should shorten patent lifespans to like 10 years. And like 5 (or 0) years for pure software patents.

Things are moving faster these days, with the interwebs and all.

It's less of a problem with how long patients last, instead it’s the ease and scope of patents granted.

The former parameter (how long the patents last) is dramatically easier to define in law than the scope.

Also a matter of how many patents are accumulated by a single entity.

In days of yore (and possibly still today), IBM would reach into its bag of thousands of patents, extract a handful, and allege infringement. The target might well successfully prove otherwise.

IBM would reach into its bag of thousands of patents, and extract another handful. The first defence had already cost the target several millions in litigation, not recoverable even on a finding of non-infringement.

This was explained to me in person by an individual with a long history of fighting such fights, back in the 1990s.

Yes, 20 years in the modern world is far too long given that the pace of change is dramatically faster than it was when 20 years seems reasonable. It would motivate patent holders in their efforts to get the most from a patent, as many sit far too comfortably bidding their time which defeats the public good purpose behind patents

Are you referring to the patent encumbered display tech found in the olpc laptops?

Because those were simply phenomenal. I have two and I've never had a display quite their equal in direct sunlight.

> Because those were simply phenomenal. I have two and I've never had a display quite their equal in direct sunlight.

That's odd. I've had and evaluated the XO-1 using Jepsen's displays and found them to be of low quality for even that timeframe. Even basic things like the resolution were terrible for that time. There's good reasons why they (both OLPC and PixelQi) were unsuccessful. OLPC was a disaster and in my opinion just a way to transfer money from the education budgets of developing countries and UN funding into the pockets of people who enjoyed hanging out in swanky incredibly costly offices at 1 Cambridge Way with guys like Nicholas Negroponte, Joi Ito and Jeffrey Epstein instead of actually achieving real progress. [1]

[1] https://www.technologyreview.com/2019/09/05/133159/mit-media...

Direct sunlight being the key part of what I said; I've never had any other display that was so legible while sitting at the end of a dock with a blazing sun blasting straight down upon the screen.

Otherwise, for sure, in general conditions it was mediocre.

And yes, the whole project was sketchy as hell, in retrospect.

My Panic PlayDate, which lacks the paper-like contrast of e-ink but can refresh at 50 fps, looks fantastic in direct sunlight. I believe it’s using a Sharp Memory LCD.

So there is other tech for this.

But it's just black and white, right? Still, that sounds promising.

Yes, and the pixels can only be either black or white, not shades of grey. (Although dithering is surprisingly effective.)

My Pebble Time Smartwatch had a color memory LCD which was also easy to read in direct sunlight, but the PlayDate's screen looks a lot better.

> after present patents expire.

Which specific patents are you referring to? If you can't answer that question without googling "eink patents", then like many others who've made this claim on HN you're not in the industry and don't actually know anything about electrophoretic chemistry and don't realize what the real obstacles are. See my comment history for details.

Searching "by:robinsoh e-ink patent" over the past year turns up numerous comments, mostly variants of "I've explained this before", but none with a link to the specific explanation you have in mind. If you happen to know of a reference, it's a courtesy to others to provide it directly.

https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...

Do you mean this comment?

https://news.ycombinator.com/item?id=28465158

> but none with a link to the specific explanation you have in mind. If you happen to know of a reference, it's a courtesy to others to provide it directly.

It is unclear what exactly you want explained to you. Or what reference you are referring to. I asked what patent you are pointing to as evidence of the allegation that you made and instead of addressing that, you're asking me for evidence that no such patent exists? How will I be able to do that?

What I'm hoping for here is for you to point to the specific comment(s) you have in mind.

You're ... being somewhat less than helpful here, and are doing much the same as you've repeatedly accused others of doing: hand-waving vaguely in some general direction without being specific.

I'd be interested in discussing, or even simply understanding, what point(s) you're making. But you're failing to make them here, or indicate where you've made them previously.

If you have a specific comment that discusses the objections to the e-ink patent encumbrance concept, please link them or make them again here.

> If you have a specific comment that discusses the objections to the e-ink patent encumbrance concept, please link them or make them again here.

You seem to be intentionally engaging in a circular argument. The parent post said "after present patents expire". So please answer a simple question. Which specific patents are you referring to? Are you going to google and give a random list of eink patents? I hope you can see why I think that's a counterproductive response.

I stand by what I wrote earlier.

I'll repeat it again. " Which specific patents are you referring to? If you can't answer that question without googling "eink patents", then like many others who've made this claim on HN you're not in the industry and don't actually know anything about electrophoretic chemistry and don't realize what the real obstacles are. See my comment history for details. "

It is the equivalent of saying IBM is blocking progress in the software industry because of IBM patents.

I hope it is clear how ridiculous that claim is. That's why I asked the simple question to which I still haven't gotten an answer.

Thank you.

I was simply looking for the substantive version of your position.

I believe you've expressed it.

OK. And you've not responded to the simple question of which patent you were referring to. That makes it clear of your 'substantive'ness and again is consistent with what I've observed on HN about this type of comments.

See in part: https://news.ycombinator.com/item?id=32486570

At this point, I'm investigating the issue. I don't jump immediately to conclusions. And I'd wanted, as noted several times above, simply to understand what your own argument / evidence is.

There's also a comment in HN history by an insider using a throwaway who discusses the dynamics by which control is exercised. And it's not through specific patents, as my comment linked above notes. Quantity has a quality all its own, as Stalin reputedly said.

I'm sure you can find it with as much ease as I'd turned up your own earlier relevant comments.

I suspect we'll have an opportunity to address this question again in future.

Could you state clearly that you are not an industry insider. You simply made a claim that patents were being used to block progress, but had no specific evidence for it. Correct? Very simple and allows readers to form their own conclusion about your allegations.

> Imagine where electronic ink displays could be today if E Ink wasn't such a terrible steward of the initial technology.

What do you mean? Any data or evidence for that?

I noticed some similarities in the source code to https://github.com/baskerville/plato/

Is there some common source for Kobo-compatable rust code that you both drew from, or was plato the original source?

EDIT: Nevermind, should have looked closer, you already called out that you drew from plato

> The code responsible for rendering to the eInk display is written by baskerville and taken from https://github.com/baskerville/plato

Yes, with his permission.

Reply on news.ycombinator.com