I don't even remember how badly things broke (at least on old devices) without it, despite it making absolutely no sense at all (state-extended just flips a global that dictates whether some things get flagged as wakeup sources or not).
So, don't rock the boat too much: we don't remove it, but instead of using a sleep, we use a task deadline instead, which ensures we'll keep processing input events in the right order in the meantime. We'll already have neutered input by this point, so we'll only process power events anyway.
That means that the only iffy things are potentially *when* and *where* we have to potentially cancel that task. Resume makes sense, of course, and we log an info message to make the log flow clear; but we also do so in suspend... just in case. With a warning log because that probably indicates something fishy went on.
Also cleanup the comments while I'm there, and actually rewrite the wakeup_count stuff properly so it could actually theoretically be used if ntx kernels were actually reliable. Spoiler alert: they're not, this is still horribly broken on at least Mk < 7. Works just fine on a Forma, though, so, yay.
Fix#12325
While #12256 papered over the tracking of a *single* suspend -> (resume->suspend) series of events, things still go out of sync if you tack on *more* suspend/resume events after that.
The upside is that our *actual* tracking of suspend/resume is solid, so at least we're actually doing the right thing as far as PM is concerned.
The downside is that on Kobo, the frontlight handling code is full of delays, and the ramping down/up itself also takes some time, so things can quickly overrun into the wrong event.
This means a couple of things:
* We need to cancel any scheduled frontlight toggles and ramps on Kobo, to ensure that only the one from the *last* event received goes through, in an attempt to limit the amount of potential crossover.
* Tracking fl_was_on *cannot* reliably be done from the suspend/resume handlers (especially on Kobo), as the ramps themselves may cross over the event barriers (and we potentially cancel the task anyway), so this was moved to the very few interactive callers that will actually change the frontlight state.
* On Kobo, crossover is still *somewhat* possible because the ramps take time. It's mostly harmless for the ramp down, we just need to tweak the ramp down to start from the actual intensity to avoid a weird jump on the initial step if there's an inconsistency. For the ramp up, we potentially need to manually kill the light first, because off -> on assumes it *really* starts from off ;).
Followup to #12256Fix#12246 (again)
Hopefully in the least intrusive way possible, because frontlight handling code is hell.
`self.fl_was_on` could go out of sync with the expected state when resume->suspend events happened in very quick succession, leading to it being set to false, preventing the frontlight from being turned back on on the next resume.
Fix#12246
* UIManager: Let the fb backend deal with Kaleido wfm promotion. This fixes a number of quirks that poisoned the refresh queue with spurious full-screen refreshes. See https://github.com/koreader/koreader-base/pull/1865 for more details.
* This also means we now disable Kaleido waveform modes when color rendering is disabled (remember to trash your thumbnail cache if you don't want to mix color w/ grayscale thumbnails, though).
* UIManager: Merge refreshes that share an edge, because that was driving me nuts (and would have most likely been merged by the kernel anyway). A perfect test-case is the FM, which trips two separate refreshes because of its title bar.
* ReaderFlipping: Use sensible dimensions, so that we only refresh the icon's region.
* ReaderBookmark: Only refresh the dogear instead of the whole page when toggling bookmarks.
* NetworkSetting: Make it a real boy, so it consistently refreshes properly on dismiss instead of relying on UIManager saving the day.
* Kobo: Aggressively prevent *both* suspend & standby while MTK devices are plugged-in, as both will horribly implode the kernel (we previously only prevent standby while charging).
* Kobo: Switch to 8bpp on B&W MTK devices (or when color rendering is disabled on Kaleido panels).
so as not to break the beforeWifiction shenanigans...
Which is most of them, only the Emulator subclass sets it, for...
reasons.
(That Emulator quirk is also why we can't simply scrap the whole thing
to use NetworkMgr's default imps).
Fix#12203 (thanks to @benoit-pierre for spotting that one).
This was clearly an oversight on my part when working on #10669
Devices with a single target might want to specify it in `Device.ota_model`
Devices with multiple targets want to override the function or to specify `ota_model` variants for each target.
* Kindle: Implement a NetworkMgr backend loosely based on WpaClient in order to allow feature-parity with hasWifiManager platforms. This involves dealing with the native wifid over lipc (the native IPC system, based on DBus), through custom Lua bindings (https://github.com/notmarek/openlipclua), since the stock ones lack support for the needed hasharray data type.
* NetworkMgr: Clear up leftover hallucinations from #10669, making `enableWifi` much simpler (and much more similar to `turnOnWifiAndWaitForConnection`).
* NetworkMgr: Made it clearer that `turnOnWifi` implementations *must* deal with `complete_callback`, as part of the aforementioned changes mean that it's *always* wrapped in a connectivity check, and we need that for proper event signaling.
* Android, Emu: Run `complete_callback` properly in `turnOnWifi`.
* Kindle: Support `powerd:isCharged()` on the PW2 (yes, this is random, it just happened to be my test device :D).
* NetworkMgr:disableWifi: Properly tear down any potential ongoing connection attempt (e.g., connectivity check).
* NetworkMgr:promptWifi: Make the "wifi enabled but not connected" popup clearer if there's an ongoing connection attempt, and gray out the "Connect" button in this case (as it would only lead to another "connection already in progress" popup anyway).
* NetworkMgr:reconnectOrShowNetworkMenu: Make *total* scanning failures fatal (they will lead to an immediate wifi teardown).
* NetworkMgr:reconnectOrShowNetworkMenu: Clear up the long-press behavior (which *always* shows the network list popup) so that it doesn't weirdly break all the things (technical term!).
* NetworkMgr:reconnectOrShowNetworkMenu: When we manage to connect to a preferred network on our own *before* showing the network list, make sure it is flagged as "connected" in said list.
* NetworkMgr:reconnectOrShowNetworkMenu: Make connection failures fatal in non-interactive workflows (they'll lead to a wifi teardown).
* NetworkSetting (the aforementioned network list widget): Clear NetworkMgr's "connection pending" flag on dismiss when nothing else will (i.e., when there's no connectivity check ticking).
K4 is ergonomically designed to be held with one hand (one's hand wrapped around the back and both thumb and middle finger on either PgFwd buttons).
This PR allows users to individually invert left and right page turners such that it can be operated just with one hand. It also closes#9350
Not sure if there are any other devices with two sets of page turn buttons, so currently limited to kindle, excluding kindle Voyage, but could be added too, albeit with some gymnastics.
1. Non-Kindle-specific `hasFiveWay` behavior is changed to `hasDPad and useDPadAsActionKeys`. For now they remain Kindle-specific in practice, unless one sets `useDPadAsActionKeys = yes` in a user patch.
2. With that disambiguation out of the way, `hasFiveWay` itself is further disambiguated into `hasScreenKB` and `hasSymKey`, as per the actual property being used, rather than something that tends to correlate with it. (It needn't be Kindle-specific per se, but non-Kindle devices have equivalent shortcuts with for example `Shift`.)
Running the emulator with `DISABLE_TOUCH=1` will set `hasSymKey = yes`, which can be tested with right shift.
Closes#11887.
Switch to a new `input.fdopen` API & wrapper so we can keep the fds opened by `fbink_input_scan` instead of closing them to re-open them right after that...
This should hopefully help on racy zForce devices that attempt to handle power management when opening/closing the device. We know this sometimes horribly fail to re-activate the IR grid (c.f., our manual activation on resume), but this apparently could also happen here (re: #11844) because of the quick succession of open->close->open.
Many PocketBook devices include a web browser, but when clicking a link in KOReader, there was no option to open the link in the browser, there was only an option to show a QR code (which can then be scanned by a smartphone).
This commit implements `canOpenLink`/`openLink` on PocketBook using the "browser.app", if available.
Tested on PB740 (InkPad 3).
Fixes: https://github.com/koreader/koreader/issues/11782
Related: https://github.com/koreader/koreader/issues/6597
* Kindle: Don't forget to open INPU_DPAD devices for the fiveways. Somehow managed to skip my mind, they're often on a separate input device.
Regression since #11807
* Update FBInk to fix a few cases of input_scan misdetection (on misconfigured drivers (e.g., no DIRECT prop on supported kernels), or old kernels with no EVIOCGPROP support).
Fix#11824
* Kobo: Drop a bunch of if ladder crap and switch to auto-detection of input devices via fbink_input
* Kindle: Drop an even larger bundle of crap to do the same ;p. (re: #11392)
* ExternalKeyboard: Switch to fbink_input to whitelist keyboards instead of the manual parsing of caps via its FindKeyboard class
* Input: Extended open/close wrappers to handle logging & tracking of dupe open/close calls.
* Support the Clara B&W, Clara Colour & Libra Colour
* Enable HW dithering on *all* the Kobo MTK devices
* Enforce 32bpp instead of 8bpp for Kobo devices with a color panel (the driver doesn't actually support 8bpp anyway)
* Enable standby support on MTK (whenever possible, i.e., not when plugged in, as that is horribly, horribly broken).
* Enforce the dedicated "color" waveform mode for image content in ScreenSaver, ImageViewer & Reader.
* Fix charging LED support on MTK
* Tweak the frontlight ramp on MTK + LM3630 so that it actually ramps smoothly
If there's only one contact, we won't get an ABS_MT_SLOT, so we need to
make sure we fall back to the main finger slot once we've caught a tool
switch.
Also, move the dedicated pen slot further away, so it has zero chance of
being detected as a potential buddy contact to a finger contact.
Fix#11514
@hius07 mentioned something to that effect a while back, makes sense.
Unlike the set of checkmarks in the dev settings, this one flips both
debug + verbose at once, *and* asks for a restart for framebuffer's
sake.
Also update the "Report a bug" spiel to request verbose debug logs.
We currently don't do anything with it, but this might help someone come
up with fancier smartcover handling, like we do on Kobo...
Simplify the fake events w/args checks:
We can just hitcheck the table directly, no need for another hash
Also catch ExitedSS on Kindle.
And, again, dn't do anything with it ;p.
* 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.
