pro1-los Fn passthrough

[Slion 1,200]

To keep on improving on our Lineage OS keyboard driver implementation here is a proposal about Fn passthrough.

At the moment Fn modifiers AKA Yellow slant arrows are being handled internally by the driver and not passed as such to the application layer. Which on one hand is needed, notably to generate the proper key scan code without modifiers, think / and ?, however on the other hand it starves the application layers from an otherwise perfectly valid modifier which could be used in custom KCM layout notably to improve international characters support on thumb keyboard.

Therefore this suggestion is about passing the Fn modifiers to the application layer when there is no specific Fn keymap for the key being hit.

Basically if a key scan code is the same in both Fn and unmodified keymap then pass on the Fn modifier to the application layer instead of filtering it out.

I reckon this should be straight forward to implement and should otherwise have no impact on the current driver behaviour. Much like my earlier Alt+Tab patch it will be a best of both world implementation.

That would actually give KCM modders and applications not one, but two modifiers to work with since left and right Fn keys are not hardwired and can be distinguished by the driver.

[Sean McCreary 328]

Having done this before, the changes are straightforward. See:

https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/315183

[Slion 1,200]

16 hours ago, Sean McCreary said:

Having done this before, the changes are straightforward. See:

https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/315183

Thanks for putting this together.

I have not tested it but from looking at the code I fail to see how Android will understand those new scan code you introduced as Fn.
Also From the KCM documentation there it no such thing as left and right function so I was thinking we should report them as left and right meta. However I don't know what meta is usually used for on Android so maybe that could conflict with other features.

Your changes just report every Fn regardless of the mapping. That's not what I had in mind.

On 8/28/2021 at 9:55 AM, Slion said:

Therefore this suggestion is about passing the Fn modifiers to the application layer when there is no specific Fn keymap for the key being hit.

For instance your patch would not be able to report '?' or '/' without the the Fn modifier which is not desired.
We want Fn passthrough only when no specific key was defined in the Fn keymap.

[EskeRahn 5,427]

3 hours ago, Slion said:

...meta is usually used for on Android

It is the key often represented with a magnifier glass for search, Also used combined for short cuts - I have no idea what else it is used for...

[EskeRahn 5,427]

3 hours ago, Slion said:

We want Fn passthrough only when no specific key was defined in the Fn keymap.

Indeed, it would be clever if Fn was a modifier if (and only if) not hardcoded to produce a plain key (physically not present on the Pro1)

(And whether this is to be Fn or Alt is an entirely different discussion *LOL* )

[Sean McCreary 328]

3 hours ago, Slion said:

Thanks for putting this together.

I have not tested it but from looking at the code I fail to see how Android will understand those new scan code you introduced as Fn.
Also From the KCM documentation there it no such thing as left and right function so I was thinking we should report them as left and right meta. However I don't know what meta is usually used for on Android so maybe that could conflict with other features.

Your changes just report every Fn regardless of the mapping. That's not what I had in mind.

For instance your patch would not be able to report '?' or '/' without the the Fn modifier which is not desired.
We want Fn passthrough only when no specific key was defined in the Fn keymap.

Allocating new keycodes is a workaround for a problem with input_report_key(), as it does not work for keycodes as large as KEY_FN (0x1d0, 464). Android supports remapping in the key layout file, and this is the strategy I have used in the past to generate Android keycodes. You can see the full list of Android keycodes here:

https://github.com/LineageOS/android_frameworks_native/blob/lineage-18.1/include/android/keycodes.h

Android uses the meta key for shortcuts, which is why the 'F logo' key is mapped to meta. For example, meta+B will switch to the web browser from anywhere in the OS.

Making the key generate different keycodes based on context will require a different approach, but the patch also demonstrates how to make the left and right Fn keys independent. There are six keys on the Pro1 keyboard designed to be modifiers: home, shift, ctrl, alt, fn_l, and fn_r. See

https://github.com/LineageOS/android_kernel_fxtec_msm8998/blob/lineage-18.1/arch/arm/boot/dts/qcom/msm8998-qrd-skuk-t5.dtsi#L440

for the configuration of the (Linux) keycodes these generate. These six keys have dedicated GPIO pins on the SoC, so they are guaranteed to not interfere with each other or any of the keyboard matrix keys. All other keys are subject to 'ghosting', and may mutually interfere when pressed simultaneously.

Edited August 29, 2021 by Sean McCreary
Fix typo

[EskeRahn 5,427]

37 minutes ago, Sean McCreary said:

Android uses the meta key for shortcuts, which is why the 'F logo' key is mapped to meta. For example, meta+B will switch to the web browser from anywhere in the OS.

Maybe the usage of the Logo/Meta-key as the selector for the non existent physical keys would be even better than Alt/Sym/†, so the hardcoding does not touch the normal modifiers at all.

This way any 'missing' key produced with Logo could be used combined with any modifier.

And obviously if Logo is not pressed with a recognised key, it should be handled as Android Meta.

The only drawback I see with this is that the Logo key pressed alone would not act as a Meta pressed alone, but plain Meta could be mapped just like any other 'missing' key.

....One could perhaps even map if meta was pressed before shift and ctrl, to get RightCtrl and RightShift - just a thought.

[Sean McCreary 328]

FWIW, I chose to map the 'F logo' (a.k.a. home) key as meta to mirror the app shortcut feature in stock. Of course, it works differently, and it uses the shortcut implementation built into Android rather than customizations in the launcher app. But the customized launcher is not open source, and we did not have permission to redistribute it.

[Hook 2,945]

14 minutes ago, Sean McCreary said:

FWIW, I chose to map the 'F logo' (a.k.a. home) key as meta to mirror the app shortcut feature in stock. Of course, it works differently, and it uses the shortcut implementation built into Android rather than customizations in the launcher app. But the customized launcher is not open source, and we did not have permission to redistribute it.

Wow, I hadn't even noticed that the F-logo key was now indeed working as the search key  with the Android keyboard short-cuts.   Thanks.  I also (though I may not be interpreting correctly) would hate to see any keyboard feature be exclusive to the launcher as I always use different launchers.

As long as I'm  interrupting. thanks to all of you working on this.  Most of the current keyboard conversations going on are way over my head, but I'm sure I'll benefit in the long run from what you folks accomplish  @Sean McCreary, @Slion, @VaZso, @Rob. S., @EskeRahn Thanks! 

[Sean McCreary 328]

1 hour ago, Sean McCreary said:

Android supports remapping in the key layout file, and this is the strategy I have used in the past to generate Android keycodes.

For an example of how to use the key layout file (.kl) to remap Linux keycodes to Android ones, see: 

https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315173/1

That patch maps the Linux keycode KEY_CYCLEWINDOWS (154) to the Android keycode APP_SWITCH.

Beware that the symbolic names for Android keycodes are not exactly the same in the C++ source code and the Java source code or the key layout files 😕 This can be a source of confusion and frustration.

Edited August 29, 2021 by Sean McCreary
Fix typo

[Slion 1,200]

@Sean McCreary Thanks for sharing that with us that helps a lot understanding it all.

Moving forward I think we should have the following mappings:

The left Fn key should be passed through as FUNCTION when no specific keymap entry is present.
The right Fn key should be passed through as ALT_RIGHT when no specific keymap entry is present.
The Sym key should be remapped to SYM instead of ALT_RIGHT.

That would give the application layer maximum opportunities for customization using KCM files.
It should enable actual Alt+Tab using right Fn+Tab even though special handling in the driver might still be needed.
It stays as close as possible to matching prints on keyboard keys.

[Sean McCreary 328]

On 8/30/2021 at 5:15 PM, Slion said:

@Sean McCreary Thanks for sharing that with us that helps a lot understanding it all.

Moving forward I think we should have the following mappings:

The left Fn key should be passed through as FUNCTION when no specific keymap entry is present.
The right Fn key should be passed through as ALT_RIGHT when no specific keymap entry is present.
The Sym key should be remapped to SYM instead of ALT_RIGHT.

That would give the application layer maximum opportunities for customization using KCM files.
It should enable actual Alt+Tab using right Fn+Tab even though special handling in the driver might still be needed.
It stays as close as possible to matching prints on keyboard keys.

I'm not sure we will ever come to a general agreement about how the keys *should* be mapped. Consequently, I think we should concentrate on enabling even more flexible remapping options, and allow sophisticated users to choose what mappings work best for themselves and their language. I've posted a brief outline proposal in the old remapping thread, and I would appreciate your feedback on the idea.