Will Bluetooth hardware keyboards ever be supported?

[arooni]

I have a boox nova air arriving today and plan on reading mostly with koreader. I think I had asked this before on GitHub but was wondering if hardware keyboards would be supported. Would be very handy for taking notes on a highlighted passage i'd like to recall later

[pazos]

Originally Posted by arooni

I have a boox nova air arriving today and plan on reading mostly with koreader. I think I had asked this before on GitHub but was wondering if hardware keyboards would be supported. Would be very handy for taking notes on a highlighted passage i'd like to recall later

It is doable but not trivial to implement.

There're no native methods that emulate what https://developer.android.com/refere...nicodeChar(int) does and include a JNI call each time a key is pressed is too costly and leads to missing keystrokes.

We might need to implement this the other way around (proccesing all keystrokes while we're in inputText state and send the resulting code to our lua loop using a named pipe, pretty much like we're already doing for generic android broadcasts in https://github.com/koreader/android-...entReceiver.kt).

If some developer is willing to do the job please open a new ticket in https://github.com/koreader/android-luajit-launcher. What's required for the task is familiarity with android SDK (or programming in general and willing to learn a new platform) and a few free hours to tinker and test solutions.

TL;DR: No ETA, patches welcome.

[Frenzie]

There has to be a way to avoid dealing with direct button events? Similar to how pasting works on Android, and how we've done the input on SDL. Because implementing keyboard layouts other than QWERTY (or whatever the dev prefers) would be patently ridiculous.

[pazos]

Originally Posted by Frenzie

There has to be a way to avoid dealing with direct button events? Similar to how pasting works on Android, and how we've done the input on SDL. Because implementing keyboard layouts other than QWERTY (or whatever the dev prefers) would be patently ridiculous.

Copy / paste also goes through JNI but it is cheap because it is impossible for the user to copy/paste stuff a few times per second.

The input model of the SDL port is what I had in mind when I talked about "getUnicodeChar". The function can be called through JNI from https://github.com/koreader/koreader...droid.lua#L115. We just need to get a few more values from "android.lib.AKeyEvent_*" such as the key modifiers aplied for current stroke.

The function will return 0 if the key isn't intended to be translated to unicode (ie: the back key) and a positive value that can be casted to a char otherwise.

That unicode char already handles keyboard l10n/distribution and works for both hardware keyboards and other IMEs.

It just happens it is slow to be called in that loop, even if we do that only when we want to register keyboard events, like we're doing on SDL.

So my suggestion would be: in inputState mode we don't consume key events in native code so they can be sent to managed code where we can do getUnicodeChar without the JNI penalty.

Please do notice that, with current approach, almost all key events won't be catched from JVM as we do consume them in https://github.com/koreader/koreader...droid.lua#L208

[Frenzie]

I have to say I find it surprising that it's so slow that you'd actually notice it, rather than slow in the 10 ms is an absolute eternity to handle a little keypress but you'd probably never notice it sense.