Currently only tested on Ubuntu-touch emulator with framework
ubuntu-sdk-14.10 for armhf.
The ubuntu-touch port is binary compatible with the Kobo port
major changes in this PR are:
1. rename the emulator device to sdl device since both the emulator
and the ubuntu-touch target use libsdl to handle input/output.
2. ubuntu-touch app has no write access to the installation dir so
all write-outs should be in a seperate dir definded in `datastorage`.
And also probably prevent a crash when trying to enable WiFi there.
We really shouldn't even show the WiFi stuff on some of these old
devices, but at least now it doesn't crash ;).
Guard against trying to get any kind of frontlight info on devices
without one.
So far the flIntensity prop has always been there, even on devices
without one, but better not assume that'll always be the case ;).
That, and be consistent with the other lipc_handle tests.
My batch of startup script tweaks should ensure PRODUCT is always
exported.
Leave the fallback in place, to avoid blowing up in weird corner-cases I
haven't thought about.
I've tested this on a N905C. I assume this implementation never
worked (since charge_now is supposed to show state of charge), but
it would be useful to get a confirmation.
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.
This allows for Viewport debugging. It is configured via an environment
variable, EMULATE_READER_VIEWPORT. It works with Lua table syntax, e.g.:
EMULATE_READER_VIEWPORT="{x=10,w=550,y=5,h=790}"
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 adds more documentation about the viewport offset calculations
for refreshing rotated viewports.
The old behaviour also was (still) buggy, even after the latest round
of fixes. Now, the offsets when rotated are hopefully calculated correct.
The calculation did not correctly calculate the offset in rotated
modes when the rotation was 90 or 270 degrees. Under these circumstances,
getWidth() and getHeight() did return rotated values for the framebuffer,
while Device.viewport did return not rotated values.
WIP, untested, can probably simplified some more.
Good news is, it should be smarter, and thus provide a smoother user
experience :).
Relies on the relevant changes in base.
FIXME!
Needs actual confirmation from people with the HW!!
Once that's done, some device checks will probably need to be
udated in the codebase to take those new devices into account ;).
This should fix#1016.
Usage for #1016:
Create a file named "custom.event.map.lua" in the koreader directory
with the following content:
return {
[102] = "LPgFwd",
}
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.
