The future of button_scan
shermp opened this issue · comments
Have you given any thought as to how you would like to proceed with the button scanner? Keep it with FBInk? Spin it off to it's own project? Turn it into a library?
I'm sure I'm not the only person who would find it useful.
It's designed to be pretty easy to bake into FBInk and expose as a public API (I basically just have to tweak the signature, hide it it behind a few ifdefs to make it throw -ENOSYS on !KOBO), and that's probably the easiest way to go forward, because it kind of does rely on half of FBInk's private API ^^, so the only sane way to spin it off would be turning it into a binary (i.e., exactly as it currently stands).
Which would, arguably, be less useful/interesting ;).
The only question left is how much special-casing it's going to need to handle the various quirks needed to suport touch input everywhere...
(And that's just annoying in the "I don't have the HW to test it myself" way, the implementation details once we know what to do where are pretty straightforward: I just add as many new fields as necessary in the deviceQuirks struct ;D).
Sounds good. Baking it into FBInk does seem like the easiest solution, even if it doesn't quite fit the "print crap to the screen" theme that FBInk has.
As for testing, you may want to appeal to some kind souls (cough victims) on Mobileread to help test it when ready.
Yeah, I'm thinking of handling the "doesn"t quite fit" issue by isolating the implementation in a dedicated source file, and possibly keeping the standalone CLI front-end instead of accessing it via yet another flag in the fbink CLI tool...
Done in master :).
Awesome. I shall give it a go, Thank you very much.
It works! (On my H2O at least...)
I shall wait until the next FBInk release, or until things are stable before merging my wrapper updates into master.