sailfish-on-fxtecpro1 / droid-config-t5

13 stars 2 forks source link

Boot image improvements for keyboard support #28

Open Kabouik opened 4 years ago

Kabouik commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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

Kabouik commented 3 years ago

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 commented 3 years ago

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

Kabouik commented 3 years ago

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 commented 3 years ago

No, its just a simple config, so you could enable it on your build, see https://github.com/sailfish-on-fxtecpro1/droid-config-t5/commit/72970428cf04af2e293f00d2e7162b7fc9534d36

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

Kabouik commented 3 years ago

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 commented 3 years ago

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

Kabouik commented 3 years ago

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.