Sean McCreary

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.

Yes, you're right. The 'su' extra package was discontinued after LineageOS 16.0 😕 I don't use it, so I haven't been paying attention...

Android uses meta for shortcuts, e.g. meta+B to switch to the web browser, and meta+E to switch to the email app. Also, META+ALT only works as CAPSLOCK in some contexts. For example, it will cause the shift state to be 'reversed' compared to the CAPSLOCK key LED in termux.

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 O

There does seem to be a bug in the settings app that is preventing this from working 😞 I will try to figure out why.

Yes, I see KF_FN is defined as 0x0400 but there is no code to send KEY_FN based on g_logical_modifiers. BTW, keycode 464 isn't handled properly by input_report_key(), so we would probably have to use a keycode < 255 and remap it in the Android .kl file to make that work. The settings app should gain a new 'toggle' setting when a file is placed at '/data/system/keyboard/keymap'. You then need to enable the custom keymap in settings for it to be loaded into the kernel. LineageOS provides root access via 'adb root; adb shell', or with the optional 'su' add-on package.

We can't really debug the problems without a test case that demonstrates them. However, it seems like the current custom keymap ought to support the uses you describe. Specifically, you can combine keycodes with any of the flag bits to make the driver issue whatever modifiers you need: I haven't tested whether the driver will correctly handle multiple flag bits set (e.g. for CTRL+ALT+Z), but we should be able to make that work too.

I tried to read through the lengthy discussion from the past week, and I hope I got the gist. But please correct me if I mischaracterize anything below. The problem with the FinQwerty solution that worked on the stock OS is that it required a new map for each physical layout, while the set of language-specific key character maps supplied with Android were basically useless. @tdm managed to fix this by creating a new keymap layer in the kernel keyboard driver, allowing the key character maps supplied with Android to work with the built-in keyboard of the Pro1. Now, things got a little

This is normally because META+ALT acts as CAPSLOCK in Android, but does not turn on the LED embedded in the CAPSLOCK key. If your shift state is reversed, try pressing the 'F logo' and 'Alt' key next to it together.

"Oops". I have opened a change with this keymap fix at https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/315195 I think the problem is that none of us actually have a QWERTZ layout Pro1, so the keymap may not have been well tested 😞 I can revise that change with any other mapping errors you find.

Having done this before, the changes are straightforward. See: https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/315183

I have one more bit of information that might help you simplify your patch. The keycode definitions in qx1000.c support modified keycodes, e.g. KEY_TAB | KF_ALT While this does the expected thing, triggering the code path you want, it does not support multiple keyup events expected by PhoneWindowManager.java. Consequently if you make these changes: diff --git a/drivers/input/keyboard/qx1000.c b/drivers/input/keyboard/qx1000.c index db637ff17455..d53cbeb4ec7a 100755 --- a/drivers/input/keyboard/qx1000.c +++ b/drivers/input/keyboard/qx1000.c @@ -304,7 +304,7 @@ static const u16 qwerty

Yes, the behavior is a bit different. Instead of cycling through the list of apps by holding ALT (or Shift+ALT) and pressing TAB multiple times, it only toggles between the two most recent apps when TAB is pressed multiple times. But you can still select which app you want using the touchscreen. The code paths for these two methods of activating the task switcher are different. Your changes to the kernel driver are triggering this code: https://github.com/LineageOS/android_frameworks_base/blob/lineage-18.1/services/core/java/com/android/server/policy/PhoneWindowManager.java#L3421

This is a great idea, but there is a much simpler way to get most of the functionality you want. See https://review.lineageos.org/c/LineageOS/android_kernel_fxtec_msm8998/+/315172 and https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315173 With these two small changes Fn+TAB will bring up the task switcher. The behavior is a little different as you must press the key combo twice to switch to the last app (vs. automatically switching when the keys are released). Also, these patches introduce a bug that disables Alt+TAB :-( That's certainly unexpected beh

Yes, today's build has the August 5th security patches but not the fix for the keymap bug. Trying to flash an older release triggers the rollback protection in the closed source components, and will force a factory reset to recover :-( Unfortunately we haven't found a fix for the problems with the touchscreen on other devices. This leaves us with a difficult choice, between the security patches and proper keymap support when the accessibility hook is enabled. I don't have any easy answer (other than building your own OS image), but the full details of the August security patches are here:

Users on other devices reported problems with the touchscreen after this change when using certain apps. Consequently, it has been pulled for now :-( If we can fix the problems with the touchscreen, it will be resubmitted and merged again. This means next week's build will have the old bug. If this will cause you problems, please don't update until the August security patches have been merged. With luck we will have a fix by then :-)

FYI, this change was merged and has been pulled due to problems it can cause with the touchscreen and certain apps. If we can fix the touchscreen issues, it will be resubmitted and merged again.

If anyone is set up to build LineageOS, I have pushed a potential fix for this problem to https://review.lineageos.org/c/LineageOS/android_frameworks_native/+/312770 It seems to prevent the key remapping problem with AutoInput enabled.

Is this the app that triggers the problem? https://play.google.com/store/apps/details?id=com.google.android.apps.googleassistant There is also another app with a similar name from AA Mobile. I would like to be able to duplicate the problem, but I think I need more details.

I'm saying my Pro1 will generate the characters matching the key labels in the image you posted when configured correctly. If only the physical layout is set to QWERTZ, but the keyboard layout is set to English then the keys generate characters almost the same as what you are reporting.

OK, thank you for the image. Am I correct that the differences only affect the diagonal yellow arrow 'shift' on two keys? On my Pro1, when set to QWERTY and German both of the changes in cyan match the character generated by the key.

With the physical layout set to QWERTZ but the keyboard layout set to English, my Pro1 generates the following characters: 1234567890-= qwertyuiop[] asdfghjkl;' \zxcvbnm,./ This is almost the same as what you report, except 'y' is swapped with 'z', '-' is swapped with '/', and the bottom-left key generates '\' instead of '+'. Is it possible you still have a keyboard remapping app enabled, and your keyboard layout is not set to German in Settings -> System -> Languages & input -> Physical keyboard -> Builtin Keyboard ?

To make absolutely sure we are talking about the same keycap labels, does your QWERTZ Pro1 match this image? I have confirmed that my Pro1 generates the same characters for each key as shown in this image when configured to use the QWERTZ physical layout and German keyboard layout.

Could you provide a bit more information to help us develop a test case? I see you have a QWERTZ Pro1, but which languages do you want to use CTRL-space to switch among? Also, which specific keys do not produce the characters you want? If none of them are correct except 'Z' and 'Y', then I suspect you have the wrong physical layout. To check this in the settings app on LineageOS 18.1, look at System -> Languages & input -> Physical keyboard -> Advanced settings -> Physical layout. You should be able to switch between the QWERTY and QWERTZ variants there. Edit: To be v

Was FinQwerty installed when you upgraded to the 20210614 build? If you haven't added any files (e.g. an extra .kcm file in /data/system/devices/keychars/), then deleting FinQwerty ought to restore your device to the 'vanilla' state I used for testing.