Workarounds for a Lux 4 with broken screen?

[wold]

As some know, I fiddle a bit with PocketBooks tools for annotations and tools. For some time now I desired having a spare reader for testing, not needing to connect my Lux 5. Broken, or older (also nice for checking firmware compatibility), it's all OK.

So I got this Lux with a broken screen for 10 euros, a gamble. Advertised as a Lux 5, it turned out a Lux 4 - not such a issue, though I'd hoped to get either a spare mainboard or screen for my Lux 5 in the deal. The lux4 does support firmware 5.x.

As for the device, the screen was half functional as hoped. After fiddling with it, the lower half revived, showing the top half. As the touch isn't adjusted, navigating is half guesswork, using a Lux 5 next to it (running 6.7...) Doing so allowed enabling automatic PC connection (called PC-Link in 5.x). That turned out lucky, as by now the entire screen refuses to update. Sadly I didn't had the foresight to add annotations for testing with AVATeR, though testing book data with firmware 5.x is now possible, even without a working screen.

As for the question:
New screens are pricey, making buying a working second-hand or a new one more sensible. I do wonder if a VNC-like mode hooking into the ink's screenbuffer is possible, showing it on a PC. e-readers for testing would then come cheap So far I am aware of the `sunxi-tools` and the onboard serial port, but unsure if these can help.

As for now the options are twofold:
- updating to firmware 6.x, and syncing it with my Lux 5. Updating will be the hardest part, but could be done side-by-side with the Lux 5... though 6.7 didn't make it to the lux4 yet. Might need to go back to 6.5 on the Lux5...

- keep it at firmware 5.x. If someone can supply a more completely populated 5.x books.db, I'd drop that in for testing (got a 5.x explorer.db once).

To be continued...

As an aside, the e-reader market here seems bonkers. 12 year old Kobo Touch/Glo's get bids up to 50E easily, even with the model ID mentioned (if for, say, inkbox development, understandable). For a Sony this seems more logical, being discontinued alltogether. Broken pocketbooks (screens usually) tend to go cheaper.

[jrw174]

I think this is for the lux 4. V5.20

http://download.pocketbook-int.com/f...0.852_user.zip

[jrw174]

As long as the table structure is the same in both versions, it should be easy to copy over. If not, nothing a bit of SQL couldn't handle

[wold]

Originally Posted by jrw174

As long as the table structure is the same in both versions, it should be easy to copy over. If not, nothing a bit of SQL couldn't handle

I now recall having once received a 5.x books.db (with annotations) to fix a bug IIRC there were no substantial changes from 5.x to 6.x, and the bug involved a faulty assumption (read: over optimization). I think I'll keep the reader at 5.x for testing.

Your remark reminds me: buried deep in the 5.x updater, are scripts for upgrading the explorer DBs (the one with the books). One can extract the updater whole or in part using https://github.com/Vanuan/pocketbook_free_swupdate, but its so old it fails partly, and doesn't handle 6.x IIRC. Might be worthwhile to update it, as it provides an easy way to check for changes.


Remains the screen. What I'm now curious about is hacking the part that generates the screen buffer or bitmap, and extract that image. This seems to involve the (closed) libinkview driver. Attempting this will likely fail in more than one way, we'll see. First stop should be accessing the device root.

ps. Got a bit of deja vu re-reading this last paragraph. Wasn't there a similar advice some months ago?

[rkomar]

You probably have some key press linked to taking a screenshot. If so, there is no need to write your own app for that.

[wold]

Originally Posted by rkomar

You probably have some key press linked to taking a screenshot. If so, there is no need to write your own app for that.

Good suggestion. There's no default screenshot key set on my Lux5 (6.7), and for 5.x it seems the same, also judging from the config.
One could configure a screenshot key manually (adding `@KA_scrn` to a `gkey`) except the config is protected by a magic number checksum... but copying from a working reader might just work

Still, for unrooted devices this would require (re)connection to view the screenshots, i.e. one can't navigate, so rooting is desired.

As for an app, it likely requires calling 2-3 SDK functions at minimum, from SSH or crontab. One issue there is trashing the disk with too many writes (->memory partition).

There is some practical use to this for me, and (hidden in the dear diary stuff) also the thought exercise of accessing a reader with a broken screen.