Support auto-detection of input devices via fbink_input #11807
Conversation
There was a problem hiding this comment.
Reviewed 3 of 3 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @Frenzie, @pazos, and @poire-z)
|
Thanks @NiLuJe ! That looks awesome and neat! Let me give it a test :D |
|
Also, will Kindle Voyage's "sensor" buttons be OK? |
Hopefully ;p.
In addition to both PR's content, you'll need this extra library in koreader's |
|
Both PRs? Am I missing a second PR? |
|
Ah, sorry, I missed koreader-base PR ref |
why would they not? |
|
@NiLuJe Result is this: |
|
L225 is this: |
|
That was on KOReader on Scribe. |
|
Oops, oversight; would only have happened on devices without keys. Previous commit should take care of it, thanks! |
|
Thanks! With this fix, it worked great! Full log, test inputs, then exit: |
This should be mostly painless, exccept possibly on the Scribe... (famous last words)
That way we're sure we'll never forget it. Also, input stuff *needs* to come before Generic.init, because it may set up input transform of its own... The gyro stuff makes.... very light of that fact, though :/.
accelerometer axes
We keep the FindKeyboard class around because it's a pretty good implementation and a great source of documentation/inspiration.
We don't want to define it multiple times in case of funky caps, and it's likely to be event0 anyway.
Instead of having to deal with this in Device or Plugin implementations...
The default imp is not FFI at all, it's a Lua/C module. True, we *also* have platform-specific imps via FFI, though.
number. Update ExternalKeyboard accordingly, and make it ask for an explicit Input close on unplug. We previously relied on an internal ENODEV check in the Lua/C module.
Also tweak logging some more
Deduping & logging is handled by Input itself
That nobody ever uses because it requires both a rooted device, *and* manual intervention to allow access to the char devices.
The FFI wrappers don't use it anyway
In cases the input backend already closed the fd, we still need to clear our array
We still need this wrapper to clear the hash, as we can't do that from the C module.
|
Moved the logging & dupe protection logic to Input itself, which requires a mild API addition to the Lua/C module. And to rework the wrappers for the custom FFI imps so as not to break on that, because the standard wrappers expect a concept of paths & fd to begin with, and particularly that (Lua) open/close take a path, as it's used to index a hashmap. Since none of the FFI imps do that (they pass no arguments), they need simple wrappers that do nothing more than forward the call. |
There was a problem hiding this comment.
Reviewed 7 of 7 files at r4, 1 of 1 files at r5, all commit messages.
Reviewable status:
There was a problem hiding this comment.
Reviewed 3 of 3 files at r6, all commit messages.
Reviewable status:
Somehow managed to skip my mind, but, IIRC, they're often on a separate input device. Regression since koreader#11807
…input-scan misdetections (#11827) * 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
Depends on koreader/koreader-base#1782 & koreader/koreader-base#1785
This change is