Sean McCreary

FYI, the DeviceSettings UI fixes will be in tonight's official build. If there is any problem applying the custom keymap, the user will see a 'toast' error notification and the custom keymap will be toggled back off again. This resolves the problem that there was no feedback when things go wrong. To test, you can use any keymap with a syntax error. I have been using this one for testing: 70:0000:0000 Since there's no key 70, this generates EINVAL which triggers the failure notification and modified UI behavior. I'm sorry this problem wasn't noticed before causing VaZso so much f

Now that custom keymaps are working, you can remap the 'up arrow' key to '/', with Android handling shift+'/' -> '?' with the following: 04:0035:0067 I chose to remap Fn+'/' to 'up arrow' so you can still use that, but it overwrites the default keycode of 'page up'. That's the '0067' part in the string above, where 'page up' would be '0068'

These two changes have been merged, and are in the 20210906 build for Pro1. If you have any trouble using a custom keymap, please open a new bug report following the instructions here: https://wiki.lineageos.org/how-to/bugreport

Yes, this is a side-effect of the A/B system used by the Pro1 and other modern Android devices. When you install a full OS image, it is written to the *other* slot, but add-on packages are written to the current one. You need to reboot to recovery after installing a new OS image to swap slots.

I have changed the behavior of DeviceSettings here: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315310 The built-in keymap mods are still toggled off and disabled when a custom keymap is active to avoid interference, but you can now use the built-in keymap mods when a custom keymap is present but not installed.

That is not what I see with getevent. Android does repeat keys when they are held down, so it seems your monitor is looking at the event stream at a much higher level than the event stream from the kernel. To fix this behavior, we probably need to be looking in the Android framework rather than the keyboard driver. I agree a GUI for creating custom keymaps would be a helpful feature. After applying CR#315276 and CR#315298, you will be able to install a custom keymap with adb: adb root; adb push my_keymap /data/system/keyboard/keymap As a sample custom keymap file, this is the KE

In CR#315342, you may disable the 'Fn-shift' by not assigning any modifier key to KEY_RESERVED. I'm not sure if you mean the separate keydown and keyup events sent by the virtual 'chording' behavior. @tdm carefully designed this so the events are sent in a 'safe' order (i.e. shift down, key down; key up, shift up). The current keyboard driver does not repeat keydown events if you hold the key down. The way I normally check the event stream sent by the driver is with 'adb shell getevent'. The output of getevent has three values, the event type (always 0001 for EV_KEY), the keycode

This is the way the in-kernel 'Fn-shift' feature that tdm wrote works. The in-kernel keymap can specify a modifier state for any key, and the driver will generate a 'chord' of key events when the key is pressed.

Beware of stuck keys with this approach 😞 I worry a bit about the side-effects of having a key both send a keycode and also enable virtual 'chording' via flags.

The built-in keymaps are disabled when a custom one is present to avoid unintended interactions. You have no control over which is applied first, and this can lead to unexpected results if we let them interfere 😉 You can always copy the built-in maps into your custom keymap if you want both, and that lets you fix any conflicts.

Don't do anything with your CR. I will push a new one rather than stomp on yours 🙂 If you like it better, you could abandon your CR sometime in the future. But my goal is to collaborate, rather than compete!

Yes, my proposal is based on your work 🙂 I am trying to simplify the implementation a bit, and extend it to more remapping cases.

That is a case which could *almost* be supported with the additional key remapping feature I am proposing. Currently the '/' and '?' mapping via Fn+P and Fn+L is remappable, as those keys are #28 and #31 in the keyboard matrix. The new idea is to allow remapping additional keys, which would allow you to use a custom keymap to remap fn_r to a single keycode. Two make the keycode it generates vary by context in the kernel, you would have to use 'shift' as the internal kernel keymap shift key (how KEY_FN is currently used in the driver), which would have side-effects for the rest of the mapping

The current custom keymap feature does not support remapping shift, ctrl, alt, home, or either fn_l or fn_r.

To be clear, I am talking about the six keys attached to dedicated GPIO lines. the SYM key is #24 in the keyboard matrix, currently mapped to KEY_RIGHTALT but also remappable using the existing custom keymap feature.

I've posted a brief outline proposal in the old remapping thread, and I would appreciate your feedback on the idea.

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.

After a bit of thought, it seems like we can enable most of the remapping scenarios people have requested if we create a method for remapping the six modifier keys: shift, ctrl, fn_l, home, alt, and fn_r. I am proposing a new remapping interface that will accept a list of keycodes for these six keys, where 0x00 will designate a key that should operate the way Fn does currently (i.e. no keycodes are sent to Android, and it 'shifts' the internal kernel keymap instead). This will allow maximal remapping of the keyboard, but also enable every possible key combination. I am specifically propos

This is the change that fixed the problem on our device, but caused problems on others: https://review.lineageos.org/c/LineageOS/android_frameworks_native/+/312770

While a couple of the people who work on LineageOS for the Pro1 read this forum, the majority don't. The best way to get our attention is to open a bug report using the instructions on the LineageOS wiki: https://wiki.lineageos.org/how-to/bugreport FWIW, I have not seen the problems with charging you are having, but I don't regularly run the battery down very far either.

468 is what Google chose to use in the Android framework to signal keyboard slider behavior, for example it is what forces the display into landscape mode when the keyboard is open. Unfortunately, they also use the same keycode for case events 😞 Changes to this will be difficult to merge into LineageOS, as the code is shared among all devices. This is why our fix for non-English keymaps and accessibility apps was rejected...

To be absolutely correct, @tdm fixed it. I just did the typing 😉

Fixed. The CR is under review here: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315298 Oh, and there is an associated SELinux policy change that is also needed, but the implementation is still under discussion

I'm curious about how you use 'su' or root access, if you're willing to describe it. For my part I haven't needed anything more than 'adb root; adb shell' for occasional administrative (mostly development) work in many years.

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.