2 ms·

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 bu

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…

TeMPOraL 2y ago
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.
- RandomThoughts3 2y ago
  > 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.
  - vundercind 2y ago
    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.
- bluGill 2y ago
  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.

TeMPOraL 2y ago

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.

RandomThoughts3 2y ago
> 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.
- vundercind 2y ago
  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.
bluGill 2y ago
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.