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.
