The concept is quite simple: stick a file on the OTA server named
something like `koreader-appimage-latest-stable` (by analogy with
`koreader-cervantes-latest-stable.zsync`), which contains nothing
but a filename.
The difference with the zsync update is that the link is then launched
in the user's browser (AppImage) or DownloadManager (Android, not yet
implemented).
* Android hasOTAUpdate = no for the moment
Supported devices:
- Boyue T61 and *some* clones
- Boyue T62 and *some* clones
- Onyx C67
- Energy Sistem (which are in fact Boyue T62 clones). Was tested on a energy pro 4.
Others may work with the same controller too, but are disabled by default.
Requires https://github.com/koreader/koreader-base/pull/798
Requires https://github.com/koreader/android-luajit-launcher/pull/96Fixes#4373Fixes#1613 (supported devices will show the "full refresh rate" option under eink settings. Others won't)
Related #4228 (need to add support for this specific device to work)
* use product as device model
* print android version (codename + number) + api at launch
* exit the application properly
* fix fullscreen switching (and disable it on newer android versions)
* gettext: lower log level for message: cannot open translation file
* android common settings refactor
* Switch all initial highlights to "fast" update
i.e., everything that does an invert
Plus a few other things that refresh small UI elements onTap
Re #3130
* Tweak refreshtype for a number of widgets:
* Fix iconbutton dimen
* Make touchmenu flash on close & initial menu popup. Full-screen on close.
* Use flashing updates when opening/closing dictionary popup. Full-screen on close.
* Switch FileManager to partial.
It's mostly text, and we want flash promotion there.
* Make configdialog & menu flash on exit
* Make FLWidget flash on close
* virtualkeyboard: flash on layout change & popup.
* Potentially not that great workaround to ensure we actually see the
highlights in the FM's chevrons
* Flash when closing BookStatus Widget
* Optimize away a quirk of the dual "fast" update in touchmenu
* Promote updates to flashing slightly more agressively.
* Document what each refreshtype actually does.
With a few guidelines on their optimal usecases.
* Switch remaining scheduleIn(0.0) to nextTick()
* Tighter scheduling timers
Shaving a hundred ms off UI callbacks...
* Cache FFI C Library namespace
* Ask MuPDF to convert pixmaps to BGR on Kobo
Fix#3949
* Mention koxtoolchain in the README
re #3972
* Kindle: Handle *all* fonts via EXT_FONT_DIR instead of bind mounts insanity
* Make black flashes in UI elements user-configurable
(All or nothing).
* Jot down some random KOA2 sysfs path
in order to have debugging facilities in framebuffer:init(), we hand
over the debug function as soon as we can.
Also, set a viewport for Kobo Mini. Hopefully, it fits most people -
I can only test on my unit.
Events have been passed to the frontend/device (or /input) code before.
Some of them have been handled in the FFI/input code, however. That
seems to be highly critical with regard to timing, though, so we just
let it enqueue the event for our code to process later. That way, a
mutex that locks the input event queue can be freed faster.
Lots of the device-related distinction wandered into
base/ffi/framebuffer_<driver>. This eases the refresh logic in
UI manager, which basically only decides what kind of refresh
to trigger. The device specific configuration in the framebuffer
driver decides how to realize that whish.
screen.lua is gone, in its place is now the framebuffer driver.
The device abstraction decides what framebuffer driver to load.
This is a major overhaul of the hardware abstraction layer.
A few notes:
General platform distinction happens in
frontend/device.lua
which will delegate everything else to
frontend/device/<platform_name>/device.lua
which should extend
frontend/device/generic/device.lua
Screen handling is implemented in
frontend/device/screen.lua
which includes the *functionality* to support device specifics.
Actually setting up the device specific functionality, however,
is done in the device specific setup code in the relevant
device.lua file.
The same goes for input handling.
