* UIManager: Init a full Geom on region-less refreshes in _refresh
* Never call refreshFull with no arguments
I got rid of the low-level nil guards, because UIManager itself guarantees that it can never happen
* Bump base (https://github.com/koreader/koreader-base/pull/1718) (fix#11303)
* Kindle: Re-enable HW dithering on the Scribe
Now that the underlying issue is fixed in base ;).
* Input: Harden setCurrentMtSlotChecked
The current implementation was assuming that the only case where we
might be missing slot storage was for the *first* contact point,
given that ABS_MT_SLOT is (if all goes well) guaranteed to be present
and come first for every subsequent additional contact points.
While this works just fine in practice, we can simplify and generalize
the check by just checking if we've actually recorded the requested
slot, even if it's not the first contact point.
The hit check is possibly ever so slightly faster than the length
computation, to boot.
* Input: Handle snow_protocol devices with newer hardware revisions that do *NOT* need the snow quirks.
If a sane input frame is detected, the snow quirks will be disabled at runtime, ensuring sane behavior.
Given the extremely non-standard behavior of the snow quirks, this is fairly easy to detect,
as a snow device will *never* emit EV_ABS:ABS_MT_TRACKING_ID:-1, so if we catch one, it's not snow ;).
(We've had reports of this on a Clara HD, FWIW)
Namely, don't recompute layouts, as they do not change.
(The gyro codepaths were already doing something similar.)
* Keep ConfigDialog, FileManagerMenu & ReaderMenu open on rotation.
(In practice, only ConfigDialog is affected, as *Menu doesn't handle the rotation event.)
* Plugged an instance leak in the aforementioned Menu classes.
* Unify behavior & code with the gyro codepaths.
Get rid of the silly precomputed tables, and do More Maths(TM) instead!
Thanks to @zwim for the magic sauce ;).
Minor simplification of the API while I'm in there, and unify the warmth
computations, do everything in the native scale (much like what
effectively happens for intensity) to workaround the silly public API
being an unhelpful PITA, ensuring consistent & effective changes.
For some mysterious reason, we init fl_warmth_max to 100 on Kobo &
Cervantes, despite this being the case on absolutely none of them.
TL;DR: We update it according to nl_max during init, but this was
missing on Cervantes.
Some platforms with horribly broken MT handling (hai, PB) will manage to
screw something up so bad that we end up with slots never running
through initialState on a contact down, so they never get an initial_tev
recorded.
Ensure we do that if necessary when switching a buddy to voidState to
avoid crashes throughout the code, which assumes everything is sane and
doesn't guard accesses to initial_tev
Re: #11196, #10950 & #11111Closes: #11111
Fix#11164 and involves a drive-by fix:
Kindle: Send Suspend/Resume event regardless of the screen saver state
If we get the events, it means stuff happened, we can't just only honor
it in the most common workflows ;).
This effectively reverts a tiny bit of #10426 (I was sort of expecting
this to be problematic at the time, and I most likely hadn't tested it).
* afterResume had *two* different implementations, so the historical one
that handled frontlight fixups no longer ran
(regression since #10426)
* isFrontlightOn was completely broken, for a couple of reasons:
* There was no is isFrontlightOnHW implementation, so when it ran, it
mostly always thought the frontlight was on, because
self.fl_intensity doesn't change on toggle off.
* _decideFrontlightState was never called on Kindle,
so isFrontlightOnHW was never really called, making isFrontlightOn
completely useless. Call it in setIntensityHW's coda, as it ought to
be. And properly document that.
Generic *was* calling _decideFrontlightState is setIntensity, but
*before* actually setting the frontlight, which makes no goddamn sense,
so get rid of that, too.
* Also fix frontlight toggle notifications (regression since #10305)
TL;DR: The PowerD API being a mess strikes again.
They'll be disabled again when the widget in question is dismissed.
This exposes a couple of semi-obvious but edge-casey footguns to the user, but a hardened implementation is way uglier. See PR for details.
They were only sent when said action was triggered manually.
Note that this is perfectly harmless, since, currently,
nothing actually responds to those events ;).
Namely, skip ramping when going to/from <= 2% frontlight, otherwise we just eat the delay for no good reason (1%), or it just stutters and looks bad (2%).
Fix#10970
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).
