Boot image improvements for keyboard support

[Kabouik]

• ✔️ Simultaneous key presses (apparently Netman on the F(x)tec Discord server managed to make it work, and it was tested succesfully in Android),
• ❓ Super on the yellow F key [should be included, but I can't see it in xev],
• Sticky modifiers,
• Toggle SFOS virtual keyboard with Sym key; could be used in combination with special vkb layouts from Openrepos, like just some special characters, just text prediction if xt9 is installed, emoji keyboard, etc. — this one might be difficult since I assume it would also need some coding to make SFOS recognize the keycode and toggle the virtual keyboard. [Probably not going to happen, the Sym key will probably be used as a more convenient key for / and ? on first and second levels.]

Any other ideas?

Additionally, it seems dead keys do not work in SFOS, but they do work in Ubuntu chroot, so I guess it is not a problem with the kernel nor the xkb layout, but rather a SFOS limitation. I'm leaving it here just in case.

[netman69]

As for the F and Sym keys, those are defined here I believe (for lineage, but that dtsi should also be used for sfos somewhere) https://github.com/tdm/android_kernel_idealte_msm8998/blob/lineage-16.0/arch/arm/boot/dts/qcom/msm8998-qrd-skuk-QX1000.dtsi#L422

[Kabouik]

From Discord:

[1:08] Craig:
Unfortunately, the Android kernel is not compatible w/ SFOS
We have to use SW_LID for the slider events (because that's what Andrid expects), but they need to use SW_KEYPAD_SLIDE
FWIW, the yellow 'F logo' key just sends KEY_HOMEPAGE: https://github.com/mccreary/android_kernel_idealte_msm8998/blob/9d41de8a5298adf8aaff77e28d1a42b51f7e7a94/arch/arm/boot/dts/qcom/msm8998-qrd-skuk-t5.dtsi#L447
That is decimal 172
I don't understand why you couldn't remap that in X
The other keys that send weird codes can also be changed in that same file
GitHub
mccreary/android_kernel_idealte_msm8998
Contribute to mccreary/android_kernel_idealte_msm8998 development by creating an account on GitHub.

[01:09] Craig: Seems like we should be able to get some functionality out of Sym and Fxtec keys in sfos.
[01:09] Craig: I really want that sym key to behave as my missing /? key.

[Kabouik]

Simultaneous key presses are now implemented thanks to @netman69 and @NotKit (and maybe others too):

devel-su
zypper ref
zypper up
dd if=/boot/hybris-boot.img of=/dev/block/bootdevice/by-name/boot_a

I think The F(x) key is supposed to be LEFTMETA in evdev_trace, but couldn't get any keycode from it in xev.

[piggz]

Is all this ok now and can be closed @Kabouik ?

[Kabouik]

I think it would still be good to have the F(x) key mapped to a keycode so that it can be used as Super, or another modifier. As far as I know, Sailfish doesn't use Super out of the box, but (1) this could be useful in chroot/LXC, and (2) maybe other useful modifiers could assigned by users depending on their needs, and (3) @elros34 mapped middle click to "Show events view" in his USB mouse patch, which demonstrates that something similar could be done.

About sticky modifiers, I don't know if that would be easily doable. On the one hand, some users would surely prefer it from what I heard of different chat channels, but on the other hand the keyboard works quite well now thanks to @netman69's multiple keypresses.

About dead keys, it's hard for me to understand what's wrong. I opened a couple issues about it on TJC on this topic but failed to really narrow down where the issue stems from. When using a xkb variant with dead keys (for instance the last one in the pro1 xkb file, see dconf instructions in comments above this variant), and installing this dirty package that adds compose instructions to xkb, then dead keys and compose feature work in Havoc. But only in Havoc (and chroot/LXC but those don't need the compose-deadkeys package as far as I remember because they run full distributions that already have the required xkb files). I don't understand what is the difference between Havoc and other applications but it seems native apps are not even looking for compose files. I believe it would be great if we could make dead keys work in Sailfish because users who are used to dead keys on their computer will miss them on the Pro1. I do (fortunately I mostly use LXC where they work so that's fine). But I do not know if that is something that can be fixed at the port level, or if it is a limitation in all native applications.

First and second paragraphs are mostly kernel improvements, and the third paragraph may be deemed out of scope, so maybe you would prefer if we close the issue here and I post this somewhere else? Let me know.

[piggz]

BTW, I already mapped the F(x) key to the home button action, which i think is pretty useful

[Kabouik]

That may be a feature that I did not notice yet because I'm still in 3.3 at the moment. It's fixed at kernel level, correct? I could flash just the new kernel without upgrading to 3.4 yet.

What are the keycode and keysym you associated with the key to make it show home?

[piggz]

No, its just a simple config, so you could enable it on your build, see 7297042

The Fx key emits a leftmeta event, so i map it to the home event instead.

[Kabouik]

Hum, could you please share your kernel version? My F(x) key doesn't emit any event at the moment when I try it in xev (LXC). LEFTMETA would actually be REALLY useful for me (even though I would prefer it on the Alt key, and Super on F(x)).

[piggz]

You can use evdev_trace -t to trace key events from sailfish

[Kabouik]

That is great, thank you. Turns out those my F(x) key does send LEFTMETA and code 0x07d too. Somehow this is not conveyed to LXC, I have yet to find why. Similar with Alt sending LEFTALT and 0x038: that one is detected in LXC and xev reports keycode 64, but yet it does exactly the same as Yellow arrow whose keycode is 108.

Those are probably related to XWayland more than the port itself. So leaving this issue open depends on whether sticky keys and dead keys/compose are in scope for the port.