We pretty much always want to turn it off on suspend, and turn it on to
some measure on wakeup.
That, and nickel's FrontLightState is completely nonsensical on my device anyway...
Which I broke the last time I touched this.
NOTE: I'm not quire sure why the bbsave/bbrestore on stop/resume did a
double check (screensaver & charging), because that effectiely disabled
it when charging, which I don't quite understand...
Also makes sure the needsScreenRefreshAfterResume flag is honored on
Kindles, because we need it on FW >= 5.7.2
Note that this *breaks* the behavior with passcode enabled, which was
unwittingly fixed in said previous changes...
re #1811
* Drops support for mocking the frontlight setting internally which may
cause incorrect in-memory values.
* Adds new supported value for `KOBO_LIGHT_ON_START` (-2), which sets
'Kobo eReader.conf' as the source to update `settings.reader.lua`'s
brightness setting on startup, thus using the value from it
indirectly.
* Adds the `KOBO_SYNC_BRIGHTNESS_WITH_NICKEL` configuration variable
which updates 'Kobo eReader.conf' every time the brightness setting is
changed within koreader.
* Fixes missing call to save brightness when modifying via two-finger
swipe.
Closes#1523.
Making sure to always show up to date info.
Also fix the battery polling cache invalidation logic to actually
work?
Should make it behave properly on devices where we handle resuming
ourselves.
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.
