Amazon reveals first color Kindle, new Kindle Scribe, and more

Just FYI, this is now a Kindle option too. https://www.amazon.com/b?ie=UTF8&node=23435466011

Finally! But what I'd really like is the last page read is the screen saver.

That would be weird, it would make it hard to know if the device is on or off.

With these displays, there's not really an "off" because as long as there's no change on the display there's no energy usage. Of course, that dies not account for the OS.

It doesn't really matter if it's on or off. This is how I have my Kobo configured via KOReader. It does put some small text "Sleeping" at the bottom in a place that doesn't obscure the page, but even this is configurable. I like it because it's like a book laying open, inviting me to jump back in.

The problem is, once you want to flip page you’ll try to press the touch screen and nothing will happen since you haven’t turned on the device with the power button (you don’t want the touch screen active always since it will drain the battery).

I guess they could add some indication on the screen it’s in ”sleep” mode though, like a frame or icon somewhere…

The whole point of e-ink screens is that the device only needs to be "on" when redrawing the screen.

In fact, with respect to the e-ink readers, a "screen saver" that turns on automatically is a bad idea that removes useful functionality - being able to keep the same page up for hours without interacting with the device is a feature, as it allows you to use it as a reference, like you'd do with a paper printout.

Yes, yes!

Honestly, I think they should optimize the time it takes a powered off device to boot up and turn the page after the user presses a button[0]. Sure, those readers tend to be full-blown Linux computers with nontrivial boot time, but approximately none of the features this stack provides are needed for simply turning the page.

I'm sure I'm underestimating the complexities of the problem, but the first idea that pops into my head is to add some flash storage that's, say, 5x the size of the framebuffer, and always keep in it the current page + next two and previous two pages (swapping pointers to avoid unnecessary writes), and have an extra microcontroller that would wake on button press, read the appropriate page from the flash buffer, and send it to the display controller. The whole process could take a fraction of the second (+ screen redraw time), all while the main OS wakes up (or boots up) in the background, and the user would experience no delays if all they're trying to do is read their book page by page. Once ready, the OS would update the flash buffer and stay active for a short while, in case the user decides they want to flip pages quickly.

--

[0] - Gosh, I keep forgetting the readers only have touchscreens now. Another reason for superiority of hardware buttons for page turning.

I use my Kobo only for technical books / diagrams etc, having it stay on the thing I'm looking at for hours is _absolutely_ a feature.

- My kobo 'refreshes' the screen at the start of every chapter.

- I typically stop reading at the end of chapters

- The so-called screen saver creates dark and light points wherever there are dark and light points on the book's cover

- The screen needs to be refreshed to return these points to homogeneity

Outcome: most of the times the screen is refreshed, I get no use of it. Most of the time I spend reading, the screen needs to be refreshed.

> Gosh, I keep forgetting the readers only have touchscreens now. Another reason for superiority of hardware buttons for page turning.

Kobo still has a reader with buttons thankfully. I don’t understand how people tolerate touchscreen on e-readers. It’s extremely distracting compared to just pressing.

There’s a “Refresh screen every:” setting under “Reader settings” where you can configure this.

Hasn’t this been the case for a few years now?

The obvious things is a tiny RTOS with enough of an ereader buffer to keep 5 screens (random number - maybe even the full boot). press the button the RTOS boots and flips the page almost instantly, then it boot linux in a VM to add more screens to the buffer, and/or take over the screen. Linux would have to be aware it is running in an RTOS like that so it can take over where you left off in the boot.

For anyone with an ad-free Kindle, and running the most recent firmware, and you're looking for the Display Cover option using Amazon's documentation, and you're not finding it...like me.

It looks like earlier this year they moved the option out of Settings > Device Options and it's now located in Settings > Screen & Brightness. Which ironically doesn't seem to be documented anywhere that I can find.

I stopped using one ereader we had because the damn touchscreen kept flipping the page if e.g. a blanked brushed it while I was reading in bed.

Buttons were absolutely perfect for this use case, on a dedicated e-reader—less so, say, an iPad mini that also does other stuff, but also those nicer touchscreens don't accidentally trigger as often so it's not as big a problem. Touch screen is nice for navigating menus but should be disabled when reading.

"on" in this case mainly means whether it's unlocked and reacting to input. It can make sense to have no distinct lock-screen, but I can also see it leading to frustrated users who are annoyed by not knowing if the device reacts to input or not.

boo, book cover on lock screen not available for Scribe (yet)