Sean McCreary

It does this because F(x)tec makes the key generate KEY_HOMEPAGE. The fix is to change this in the kernel source, e.g. https://github.com/LineageOS/android_kernel_fxtec_sm6115/commit/41b535243dce9e057069adda494cbbaf8c720f35

FYI, some Linux distributions (like Debian Bullseye) name the prerequisite package "python3-protobuf", and you may need to set "PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python" to get the script to work.

This is where that second hexadecimal number in each keymap rule is useful. It allows you to specify an alternate Linux event code plus any combination of Shift, Alt, AltGr, Ctrl, or Fn. F(x)tec moved the yellow labels around in ways that can't be matched by only rearranging the keys, and tdm gave us another layer in the kernel to fix this 🙂 Say the yellow label was 'Å', but the .kcm file defined that as 'AltGr + some other key'. You would define the last number in the keymap rule to be that other key, but with the 'AltGr' flag set as well, e.g. key_code | KF_ALTGR == key_code | 0x1000

There is another layer, the .kcm file. For Scandic models of the Pro1-X I made this key character map: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1x/+/348323/5/AsantiKeypad/res/raw/keyboard_layout_fxtec_scandic.kcm The Unicode code point for Å is U+00C5, which is mapped from the key code for "LEFT_BRACKET" (decimal 26) here. I used Android's Swedish language overlay as the basis for the F(x)tec Scandic default .kcm file, and I suggest you choose the language overlay closest to your own and set up your kernel keymap to match. This unfortunately excessively com

Yes, this should work in LineageOS 20. Please let me know if it doesn't, and I will fix it 🙂 Download this file: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/348111/3/devicesettings/QWERTZ_keymap There is also a full keymap for Pro1 QWERTY in the same CR.

As another example, I can't build crosshatch from scratch without OOM errors, even with 32 GB RAM. The problem is that the build system doesn't avoid scheduling too many memory-hungry jobs in parallel, and LTO of the kernel takes ~40 min to complete on my build system. LTO uses 6GB of RAM, and will still be running when all of the Java and dex2oat jobs want > 2GB each. Some people swap to zRAM as a workaround, but sometimes the build will complete if you wait for the partial build to fail, and then immediately run 'brunch' a second time.

LineageOS is a group project, and support for the Pro1-X wouldn't have been possible without Georg Veichtlbauer [email protected]'s efforts. And of course we built upon @tdm's work on the Pro1 as well.

The general idea is for Settings to set a global value, and and a modified KeyCharacterMap.java to check that value instead of depending on the .kcm files. The negative reviews are about the various possible ways to do this: a setting, a system property, etc. An instance variable isn't usable for this as each app gets a different instance of the KeyCharacterMap object, so there's no way to use a method in the class itself and have the change take effect in all instances. The normal way to do this is to add a new setting in LineageOS' SDK, but unfortunately the SDK can't be linked against the c

lineage-20.0-20230212-UNOFFICIAL-pro1x.zip disables the "press twice to lock" feature. You can still press just one key at a time, but you'll need to press Shift/Alt/AltGr before every key you want to modify. Note that Caps Lock is available if you want more than one capital letter in a row. I hope this small change is a compromise everyone can accept. Early feedback on my patch to make the keyboard type configurable from Settings has been negative, suggesting it would be unlikely to appear in official builds of LineageOS. If you are building your own OS images and are interested in th

LineageOS 20 is stable and usable on the Pro1, but I don't use Magisk. Please report any bugs you might find by following the instructions on the LineageOS Wiki. FWIW, I never liked Android 11 much either.

This feature was added to official builds for the pro1 in Nov 2021 with this change: https://github.com/LineageOS/android_kernel_fxtec_msm8998/commit/a340af4b4e360d11cd53d7ad199950faac344b78 It supports remapping the yellow arrow keys to any Linux key event code, but doing so prevents them from triggering the alternate keymap in the kernel. You can remap them both to AltGr and just ignore the kernel 'keymap shift' feature entirely. In fact, I used this feature to add the layout mod that makes the left yellow arrow key AltGr without requiring a custom keymap: https://github.com/Linea

By popular demand, lineage-20.0-20230209-UNOFFICIAL-pro1x.zip changes the built-in keyboard type to 'ALPHA'. This makes the Shift, Alt, and AltGr keys 'sticky' in some contexts, where Caps Lock is active for the next keypress. It does not make Ctrl, or Fn sticky, and has some other UI side effects. I also added a change log at the end of README.md in the same folder as the OS images. To cut down on forum spam, I will stop announcing minor changes and only post notices for major bug fixes or similar large changes. EDIT: It's Android's "press twice to lock" feature of ALPHA keyboards t

lineage-20.0-20230208-UNOFFICIAL-pro1x.zip includes the February ASB patches (with date 'February 5, 2023'), and removes the mapping rule for 'Caps Lock + Backspace -> Forward Delete'. After a only few minutes of testing I realized this was a terrible idea, as it made correcting my typos with Caps Lock on much less natural 😉

To help you create your own custom keymaps, I updated @Slion's excellent keyboard map for the Pro1-X QWERTY layout and added the key numbers for each of the six modifier keys ('F logo' Fx, Shift, Ctrl, Alt, and right and left "yellow arrow" Fn). Remember that the two Shift keys are actually the same, as are the two Ctrl keys. Unfortunately, you can't map right and left Shift to different key codes, or right and left Ctrl either 🙁

I have uploaded lineage-20.0-20230207-UNOFFICIAL-pro1x.zip, adding the option to remap the 'Del' key to '\' to improve compatibility with native Android language overlays. While this won't improve agreement between the labels printed on the keys and the characters they generate, it does eliminate the 'missing keys' problem. For example, with the 'English (US)' language overlay enabled, the key labeled '?' will produce ';' and ':' (with Shift) like an ordinary QWERTY keyboard, and the key labeled '/' will produce '/' and '?'. Remapping 'Del' will make that key produce the two missing characters