This reverts commit e7e0d2edb6.
Whatever's actually going on with nightmode, this isn't it.
This was independently confirmed to behave as expected,
and the issue that prompted this was *not* fixed by this commit.
* Device: Add a `hasSeamlessWifiToggle` devcap to complement `hasWifiToggle`, to denote platforms where we can toggle WiFi without losing focus, as this has obvious UX impacts, and less obvious technical impacts on some of the NetworkMgr innards...
* Android: Mark as `!hasSeamlessWifiToggle`, as it requires losing focus to the system settings. Moreover, `turnOnWifi` returns *immediately* and we *still* run in the background during that time, for extra spiciness...
* NetworkMgr: Ensure only *one* call to `turnOnWifi` will actually go on when stuff gets re-scheduled by the `beforeWifiAction` framework.
* NetworkMgr: Ensure the `beforeWifiAction` framework will not re-schedule the same thing *ad vitam aeternam* if a previous connection attempt is still ongoing. (i.e., previously, on Android, if you backed out of the system settings, you entered the Benny Hill dimension, as NetworkMgr would keep throwing you back into the system settings ;p). This has a few implications on callbacks requested by subsequent connection attempts, though. Generally, we'll try to honor *explicitly interactive* callbacks, but `beforeWifiAction` stuff will be dropped (only the original cb is preserved). That's what prevents the aforementioned infinite loop, as the `beforeWifiAction` framework was based on the assumption that `turnOnWifi` somewhat guaranteed `isConnected` to be true on return, something which is only actually true on `hasWifiManager` platforms.
* NetworkMgr: In `prompt` mode, the above implies that the prompt will not even be shown for concurrent attempts, as it's otherwise extremely confusing (KOSync on Android being a prime example, as it has a pair of Suspend/Resume handlers, so the initial attempt trips those two because of the focus switch >_<").
* NetworkMgr: Don't attempt to kill wifi when aborting a connection attempt on `!hasSeamlessWifiToggle` (because, again, it'll break UX, and also because it might run at very awkward times (e.g., I managed to go back to KOReader *between* a FM/Reader switch at one point, which promptly caused `UIManager` to exit because there was nothing to show ;p).
* NetworkMgr: Don't drop the connectivity callback when `beforeWifiAction` is set to prompt and the target happens to use a connectivity check in its `turnOnWifi` implementation (e.g., on Kindle).
* Android: Add an `"ignore"` `beforeWifiAction` mode, that'll do nothing but schedule the connectivity check with its callback (with the intent being the system will eventually enable wifi on its own Soon(TM)). If you're already online, the callback will run immediately, obviously. If you followed the early discussions on this PR, this closely matches what happens on `!hasWifiToggle` platforms (as flagging Android that way was one of the possible approaches here).
* NetworkMgr: Bail out early in `goOnlineToRun` if `beforeWifiAction` isn't `"turn_on"`. Prompt cannot work there, and while ignore technically could, it would serve very little purpose given its intended use case.
* KOSync: Neuter the Resume/Suspend handlers early on `CloseDocument`, as this is how focus switches are handled on Android, and if `beforeWifiAction` is `turn_on` and you were offline at the time, we'd trip them because of the swap to system settings to enable wifi.
* KOSync: Allow `auto_sync` to be enabled regardless of the `beforeWifiAction` mode on `!hasSeamlessWifiToggle` platforms. Prompt is still a terrible idea, but given that `goOnlineToRun` now aborts early if the mode is not supported, it's less of a problem.
* Enforce a minimal standby timer for the first standby after a resume.
* On Kobo, sleep a bit before standby.
This aims to alleviate race conditions causing visible refresh glitches on sunxi, especially when using an extremely low standby timer (i.e., below the defaults).
Makes more sense this way.
Re: #10828
Also clarify the UIManager "no dialogs left" message, and drop the
return value, as it's meaningless, we just want to break & return.
As early as turnOnWifi.
Implement it on hasWifiManager platforms, preventing useless
connectivity checks to run when they're obviously never going to work
because you're out of range of your AP.
Also implemented a flag to notify the backend if the connection attempt
was interactive or not.
Right now, interactive is extremely restricted, it basically means the
menu checkmark, or a gesture.
The intent being that for stuff like the beforeWifiAction framework, we
don't want the backend to spawn extra UI.
Specifically, for hasWifiManager platforms, we no longer spawn the AP
scan list on failure unless the caller was interactive.
TL;DR: beforeWifiAction is now much less obnoxious when you're obviously
not able to connect.
This is semantically more correct, and should prevent platform-specific
weirdness if an ordering concern ever comes up (e.g., like it did for
the viewport stuff).
Re #10743
Note that this only makes faulty switches slightly less annoying: for a
stuck switch, instead of a string of page turns, you'll get a single
missed page turn on the tap that actually releases the stuck contact...
we use it as text anyway and test if it is the empty string also.
this fixes a crash in viewhtml when holding a selector with an empty clipboard, we try to contcate getClipboardText which is nil (on !SDL & !Android)
* Notification: Drop the fencing from #10083; it never actually helped, and had subtle side-effects we could do without.
* VirtualKeyBoard: Flash on close, otherwise, some of the fast refresh glitches may be burned into the working buffer until a flash. Making sure we flash ourselves prevent it from sticking around on the page ;).
* util: Move `writeToSysfs` to base (i.e., `ffi/util`), as we need it there (and it actually makes more sense there anyway ;p).
* Bump base for https://github.com/koreader/koreader-base/pull/1645, which is where the actual workaround (hopefully) lives.
Re #8414, #9806, #10558
It's been made redundant by the RPATH changes
The only platform that gets the dubious honor of actually needing an
LD_LIBRARY_PATH is PocketBook, because of InkView.
Co-authored-by: Benoit Pierre <benoit.pierre@gmail.com>
Bump base to pull in the aforementioned RPATH changes ;).
https://github.com/koreader/koreader-base/pull/1638
* Enable before_wifi_action & after_wifi_action on hasWifiToggle platforms (which is basically all of 'em except naked SDL).
* Decouple restoreWifiAsync from hasWifiManger, because we can do that on other platforms (namely, Kindle. Probably PB, too, but WiFi is already a mess there, and I can't test it).
* Implement restoreWifiAsync on Kindle.
* Properly flag rM as hasWifiManager & hasFastWifiStatusQuery, because it is actually both of those (it uses our wpa_supplicant backend).
* Update the KOSync checks to take these changes into account, to properly disable auto_sync if necessary.
* Really made the Network* event signaling consistent. For realz this time.
* In an effort to make the whole beforeWifiAction framework somewhat usable there, we now assume connectivity is always available on !hasWifiToggle platforms...
Namely, that swipes report the gesture's *starting* coordinates as `pos` (for hit-detection purposes), while pans (and basically everything else) use the *lift* coordinates (as well as provide a relative vector).
In each case, we now also provide a separate `start_pos`/`end_pos`, in case handlers need finer-grained data (e.g., anchoring UI elements to a swipe's lift coordinates).
Extended addition of PocketBook InkPad 4 with firmware later U743g.6.8.885 (PB743G) because its device ID was corrected from PB743g to PB743G by firmware U743g.6.8.1719.
Fix: #10539, and for context #6489, #6733, #6534
Reorganize and reword most of the settings to make it clear what actually ties into auto sync, and what doesn't. (Specifically, what happens when a pull attempts to sync forward or backward has nothing to do with auto sync, it applies in all cases; while the periodic sync *does* require auto sync).
The main point of contention, though, is that auto sync will now *always* attempt to setup network connectivity (i.e., on resume/suspend/close). Periodic sync will *not* though (the intent being that, if you use periodic sync, you're relying on the activity check to actually keep wifi on at all times)).
Since this may lead to a large amount of nagging about wifi toggles on devices w/ NetworkManager support, it is now *disabled* by default on those devices. (And given that it wouldn't have worked because of the lack of connectivity, that doesn't really make any practical difference ;p).
Additionally, given the fact that there's no way to make this behavior viable if the "before wifi" action is left at its default of "prompt", this feature now *requires* that to be set to "turn_on" (on devices where it can, of course); attempting to toggle it on will warn about that if necessary.
This change is retroactive (OTM).
Includes an assortment of fixes and cleanups, including migrating to the new LuaSettings API, which is why there's no longer a smattering of superfluous flushes.
Fix#10588
Regression since #10305
While we're there, rejig the FL toggle callback shenanigans so that implementation details don't leak through to *other* implementations.
(i.e., leave the Kobo mess in Kobo land, with only a minimal impact on the public API and its implementation).
sometimes my kindle fires the rtc alarm a tad too late so use a more generous timeout
the real fix would be to have validateWakeupAlarmByProximity return differently if the alarm is past or in the future, but i am too lazy
Make sure we only send Suspend/Resume events when we *actually* suspend/resume. This is done via the Device `_beforeSuspend`/`_afterResume` methods, and those were called by the *input handlers*, not the PM logic; which means they would fire, while the PM logic could actually take a smarter decision and *not* do what the event just sent implied ;).
(i.e., sleep with a cover -> suspend + actual suspend, OK; but if you then resume with a button -> input assumes resume, but PM will actually suspend again!).
Existing design issue made more apparent by #9448 ;).
Also fixes/generalizes a few corner-cases related to screen_saver_lock handling (e.g., don't allow USBMS during a lock).
And deal with the fallout of the main change to the Kobo frontlight ramp behavior ;).
Allow disabling the hall efect sensor via the sysfs knob, so the kindle system wont sleep & wake the device
for those of use that stay in koreader, are caseless and have get spurious wakeups
* Rewrite the loop mechanism to use scheduled tasks instead of a single blocking-ish subprocess.
* Change the actual logic to be more pleasing to the eye, especially on newer devices, as those *may* natively ramp on set; and fix a bad interaction with that behavior that could lead to no ramp at all on ramp down.
* Simplify Generic's Suspend handling to deal with the refresh ordering in a saner manner. The screensaver might be visible a tad longer than before this change before the frontlight actually ramps off.
For example, to determine whether the Japanese or Chinese form should be shown.
* Dictionaries.lua - use iso3 codes everywhere
readerdictionary.lua - convert iso to bcp tag, to construct ifo_lang
isolanguage.lua - map from iso3 to full language name, map from iso3 to bcp language tag
* Make the full language names translatable
* Store ifo information from dictionaries.lua in downloaded dictionaries
Add a dedicated handler to handle mixed pen + panel, when panel sends both mt + st and stylus only st
Don't stomp on panel slots in the Wacom protocol handler
Get rid of a few superfluous nil guards
Return early in the EV_KEY handler for touch-related events (i.e., BTN_)
Some devices don't ship with iproute2 compatible tools, but may ship
with net-tools compatible ones.
Unify code w/ SDL's similar codepaths for its NetworkMgr:isConnected
implementation
Much easier to deal with thanks to the cleanup work done in #10062 ;).
* `carrier` is set to 1 as soon as the device is *administratively* up (in practice, as soon as we run `ifconfig up`). This is perfectly fine for `isWifiOn`, but absolutely not for `isConnected`, because we are not, actually, connected to *anything*, no attempt at associating has even been made at that point. Besides being semantically wrong, in practice, this will horribly break the connectivity check, because it expects that `isConnected` means we can talk to at least the LAN.
* Delving into the Linux docs reveals that `operstate` looks like a better candidate, as it reflects *operational status*; for Wi-Fi, that means associated and successfully authenticated. That's... closer, but still not it, because we still don't have an IP, so we technically can't talk to anything other than the AP.
* So, I've brought out the big guns (`getifaddrs`), and replicated a bit of code that I already use in the USBNetwork hack on Kindle, to detect whether we actually have an IP assigned. (Other approaches, like `/proc/net/route`, may not be entirely fool-proof, and/or get complicated when IPv6 enters the fray (which it does, on Kobo, Mk. 8+ devices are IPv6-enabled)).
TL;DR: Bunch of C via ffi, and `isConnected` now returns true only when the device is operationally up *and* we have an IP assigned.
Pulls in https://github.com/koreader/koreader-base/pull/1579 & https://github.com/koreader/lj-wpaclient/pull/10
cervantes kindle kobo remarkable: use sysfs carrier file to determine connection state
cleanup hasWifiManager checks
gateway check: use ip if available
Fixes: #10087Closes: #10092
isWifiOn for kindle currently returns if the interface is connected, change this to doing what is says isWifiOn the file is only present if the wireless interface is up.
isConnected pings the gateway, rely on the kernel for a more reliable check.
Whan connecting to my android phone's wifi hotspot to remote debug from my phone, the network is connected yet the phone(gateway) does not respond to pings leading koreader to shut down the connection thinking it is unsuccessful
Apparently, toggling the rtc interrupt doesn't quite work on some boards? (fix#10031)
(Drive-by tweak to UIManager: Less confusing logging when quit gets tripped both via quit
and _gated_quit (i.e., on poweroff))
Fix#10020, Regression since #10008
(hasMultiTouch is set by `Generic.init`, but we use it before that;
so just set it properly ourselves in our superclass, because we don't
actually need to rely on Generic's autodetection).
Generic is responsible for setting up the translation via input hooks;
since our own input hooks involve swapping or mirroring X/Y, we need to
run our own hooks *first*, so that the viewport translation actually
does the right thing...
Probably broken for a good long while, I'd just assumed the inaccuracies
on the H2O were due to the IR grid... :/.
Reported @ https://www.mobileread.com/forums/showthread.php?t=351340
Regression since #9902, because I'd forgotten that the default Kobo block *does* set those...
Reported by @ptrm on Gitter, thanks!
Take two, essentially revert 8a16518918
We have defaults for most of those in the Kobo superclass, so these can never really be `nil`.
If Wi-Fi is restored on resume, going back to suspend while the
screensaver is shown via the screen_saver_lock flag would have attempted
to suspend *without* killing Wi-Fi first.
This implodes on the vast majority of NTX boards, so take the usual
precautions.
* Get rid of the `canToggleGSensor` Device cap, it's now mandatory for `hasGSensor` devices. (This means Kindles can now toggle the gyro, fix#9136).
* This also means that `Device:toggleGSensor` is now implemented by `Generic`.
* Update the Screen & Gyro rotation constants to be clearer (c.f., https://github.com/koreader/koreader-base/pull/1568) (/!\ This might conceivably break some `rotation_map` user-patches).
* Input: Move the platform-specific gyro handling to Device implementations, and let Input only handle a single, custom protocol (`EV_MSC:MSC_GYRO`).
* Input: Refine the `rotation_map` disable method implemented in 43b021d37c. Instead of directly poking at the internal field, use a new method, `disableRotationMap` (/!\ Again, this might break some `rotation_map` user-patches).
* Input: Minor tweaks to event adjust hooks to make them more modular, allowing the Kobo implementation to build and use a single composite hook. API compatibility maintained with wrappers.
Adjust image colors for PocketBook color devices to supply
brighter image colors. Make it a config option so we can
adjust it to a sensible default for all devices later.
Also enable HW Dithering for color devices: the dithering
flag allows us to figure out if what is viewed is an
image or text. This way we can enable color rendering
or not based on the dithering flag.
It possibly historically never made it out of InkView in the past, but
apparently that's no longer the case and/or every other key behaves the
same way anyway, so it's harmless at worst.
Fix#9791
(This involves moving it to the instance object to avoid inheritance).
Pocketbook: Disable rotation_map on the Era (fix#9556)
It would appear that InkView handles the translation for us, now...
Get rid of the doc & seqtext fields, as they are not actually used (nor
are they particularly useful, the event handler's name should be pretty
self-explanatory).
Also, tweak the key_events documentation to highlight the quirks of the
API, especially as far as array nesting is involved...
Random drive-by cleanup of the declarations of key_events & ges_events
to re-use the existing instance object (now that we know they're sane
;p) for tables with a single member (less GC pressure).
ElimGarak1
NiLuJe
zwim
yparitcher
hasezoey
Christian Kilb
Martín Fernández
Alistair Francis
Frans de Jonge
Benoit Pierre
roshavagarga
hrdl
kpopconnoisseur
nairyo
Andrej Shadura
Sargun Vohra
Jej
Robert-Jan de Dreu
charlesangus