How to customize the keyboard layout on LineageOS 18.1?

[Sean McCreary 328]

22 minutes ago, VaZso said:

Isn't it is what I have done here?

Okay, currently if does not remap "ctrl" and kernel interface may use a similar method like what "keymap" interface does (so x:y:z), but it remaps fn_l, fn_r, F(x) keys and 0x00 will keep default behaviour.

Also, it has an option to remove special behaviour of fn key currently has as opt out, so special key transformations may also be enabled or disabled which could also make stock behaviour possible by disabling it and setting fn_l and fn_r the same as in stock Android.

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

[Slion 1,201]

45 minutes ago, Sean McCreary said:

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

@VaZso

That's my understanding too. What Sean is suggesting is definitely an extension of your work taking things even further by making it more generic. Great team work guys. 

[VaZso 1,998]

51 minutes ago, Sean McCreary said:

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

It is okay if you could keep all "features" and extend them in a way of being more customizable but not restrictive.

What should I do with the CR?

May I ask you what are you planning to do more detailed?

[Slion 1,201]

11 minutes ago, VaZso said:

May I ask you what are you planning to do more detailed?

You will be able to remap every modifiers. My understand is that he is simply planning to add them to our keymap.

Edited September 1, 2021 by Slion

[Sean McCreary 328]

9 minutes ago, VaZso said:

It is okay if you could keep all "features" and extend them in a way of being more customizable but not restrictive.

What should I do with the CR?

May I ask you what are you planning to do more detailed?

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!

[VaZso 1,998]

4 minutes ago, Sean McCreary said:

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!

I am asking because I don't know exactly how this system (Gerrit) work or what related functions it may has.

Generally what I wanted is to do something which I can use in a way I would like and what is also suitable for everyone.

...and you are right, what is also interesting would be ctrl, alt and also sym as additional modifiers to reach a maximally custoizable state.

...and I am agree it is not a competition, simply these and additoional features would be really good to have.

Also, "custom keymap" option has disabled other options when custom keymap file exists even if it was not enabled (in current LineageOS version) and adding arrows to page up/down, etc. functions would be good to be kept as a switchable option I think.

[Sean McCreary 328]

35 minutes ago, VaZso said:

Also, "custom keymap" option has disabled other options when custom keymap file exists even if it was not enabled (in current LineageOS version) and adding arrows to page up/down, etc. functions would be good to be kept as a switchable option I think.

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.

[EskeRahn 5,471]

It would be nice if the kernel remapping could be so flexible that it only took a modifier key if it was used with on of the defined remappable keys. This way more combinations would be available for the users, with the modifier used with other keys.

[VaZso 1,998]

11 minutes ago, EskeRahn said:

It would be nice if the kernel remapping could be so flexible that it only took a modifier key if it was used with on of the defined remappable keys. This way more combinations would be available for the users, with the modifier used with other keys.

I don't really understand the above.

Do you mean to only use a modifier when the remap of that key is not defined (in fn array)?

[EskeRahn 5,471]

Just now, VaZso said:

I don't really understand the above.

Do you mean to only use a modifier when the remap of that key is not defined (in fn array)?

Let me make an example.

Assume we use the left  YA key combined with the letters 'P' and 'L' to in the kernel 'emulate' two missing physical keys.
But YA combined with 'T' might not be mapped in the kernel, so in this case rather than just sending the 'T', it could be sent as a modifier+'T', for remapping  furhter down the pipeline,

[VaZso 1,998]

1 hour ago, Sean McCreary said:

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 😉 

It seems it does not re-enable them but I have remembered they were disabled completely when the file exists.

3 minutes ago, EskeRahn said:

Assume we use the left  YA key combined with the letters 'P' and 'L' to in the kernel 'emulate' two missing physical keys.
But YA combined with 'T' might not be mapped in the kernel, so in this case rather than just sending the 'T', it could be sent as a modifier+'T', for remapping  furhter down the pipeline,

The modification what I did may send a keycode on pressing a modifier while it will also generate the keycode assembled in fn-level of the keymap (if enabled).

So it behaves similarly except it will also generate the keycode on pressing/releasing the "fn"/Yellow Arrow key.

Eliminating this behaviour is possible but it needs deeper modification so it is more complicated.

[Sean McCreary 328]

34 minutes ago, VaZso said:

The modification what I did may send a keycode on pressing a modifier while it will also generate the keycode assembled in fn-level of the keymap (if enabled).

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.

[Sean McCreary 328]

1 hour ago, EskeRahn said:

It would be nice if the kernel remapping could be so flexible that it only took a modifier key if it was used with on of the defined remappable keys. This way more combinations would be available for the users, with the modifier used with other keys.

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.

[VaZso 1,998]

44 minutes ago, Sean McCreary said:

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.

Maybe it could release the key if there is a generated another key which uses a different modifier and then send the generated key.

I don't know if that (two keycodes sent in a row) has a higher or lower potential side effect than sending the keycode, sending another keycode then releasing, then releasing the first keycode (even if these keycodes are the same).
...but as it is an optional feature in that code, both the fn layer can be disabled and the fn key can be set to default behaviour.

I would prefer turning off the fn layer and turning on the FN key as a real key representation and that is why I put those functions there.

Other than that, if none of the above behaviour is problem-free (instant release and sending new code or sending new code then release as it currently does), then it may automatically forget about FN layer if the selected option is not "default" and that would not need a separate option to disable FN layer.

I haven't found side-effect yet anyway.
One thing what is different in how keyboard driver works in LineageOS is it sends the modifier several times when it is pressed.
I mean also the current driver in LineageOS will send shift several times until it is released and redefined modifiers will do the same.

So if this behaviour does not have side-effect, I was suspecting the other one may also does not cause problem, but that is a special case when FN layer is enabled but also left or right fn modifier key is redefined - the former makes almost impossible to use the latter using the default keymap what can also be replaced through kernel interface.

Edited September 2, 2021 by VaZso

[VaZso 1,998]

40 minutes ago, Sean McCreary said:

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.

I think @EskeRahn told we have an "fn layer" associated to a key (in fn array) which has a modifier but not for another key.

So "another key" would send the generally specified modifier together with a key instead of remaining silent while "a key" would only send the key/combination specified in fn array.

[EskeRahn 5,471]

15 hours ago, VaZso said:

So "another key" would send the generally specified modifier together with a key instead of remaining silent while "a key" would only send the key/combination specified in fn array.

That was my point yes 🙂

[Sean McCreary 328]

17 hours ago, VaZso said:

Other than that, if none of the above behaviour is problem-free (instant release and sending new code or sending new code then release as it currently does), then it may automatically forget about FN layer if the selected option is not "default" and that would not need a separate option to disable FN layer.

In CR#315342, you may disable the 'Fn-shift' by not assigning any modifier key to KEY_RESERVED.

17 hours ago, VaZso said:

One thing what is different in how keyboard driver works in LineageOS is it sends the modifier several times when it is pressed.
I mean also the current driver in LineageOS will send shift several times until it is released and redefined modifiers will do the same.

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 for the event (e.g. 0039 for KEY_SPACE or 008f for KEY_WAKEUP), and either 00000001 for a keydown event or 00000000 for keyup. Note the driver always issues these in pairs, and there is always an EV_SYN SYN_REPORT event (all zeroes) betwen EV_KEY events.

17 hours ago, VaZso said:

So "another key" would send the generally specified modifier together with a key instead of remaining silent while "a key" would only send the key/combination specified in fn

You can configure this behavior in a custom keymap. Simply add the 'default' modifier as a flag bit on every entry except the ones that should use a non-default modifier.

[VaZso 1,998]

1 hour ago, Sean McCreary said:

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.

In kernel messages, it is clearly seen when a keydown or keyup interrupt happens.

However, it does an automatic key repeat what also PCs have/had (Typematic Rate / Delay) which also happens to modifiers.
I was speaking about this kind of behaviour (stock LineageOS).

1 hour ago, Sean McCreary said:

You can configure this behavior in a custom keymap. Simply add the 'default' modifier as a flag bit on every entry except the ones that should use a non-default modifier.

Anyway, it would be good to have a custom layout editor in configuration UI of the system even if it only has an input field what it can save - so it would not need any kind of root access.

[Sean McCreary 328]

6 hours ago, VaZso said:

However, it does an automatic key repeat what also PCs have/had (Typematic Rate / Delay) which also happens to modifiers.
I was speaking about this kind of behaviour (stock LineageOS).

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.

7 hours ago, VaZso said:

Anyway, it would be good to have a custom layout editor in configuration UI of the system even if it only has an input field what it can save - so it would not need any kind of root access.

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 KEYBOARD_KEYMAP_FNKEYS_TEXT preset defined in the source code here: https://github.com/LineageOS/android_device_fxtec_pro1/blob/lineage-18.1/devicesettings/src/org/lineageos/settings/device/Constants.java#L33

57:0002:003b
60:0003:003c
8:0004:003d
61:0005:003e
55:0006:003f
19:0007:0040
3:0008:0041
53:0009:0042
13:000a:0043
45:000b:0044
29:000c:0057
37:000d:0058

 

[VaZso 1,998]

4 hours ago, Sean McCreary said:

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.

Yes, it may definitively happen.

[Sean McCreary 328]

On 9/1/2021 at 2:06 PM, VaZso said:

Also, "custom keymap" option has disabled other options when custom keymap file exists even if it was not enabled (in current LineageOS version) and adding arrows to page up/down, etc. functions would be good to be kept as a switchable option I think.

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.

[Sean McCreary 328]

On 9/2/2021 at 9:10 PM, Sean McCreary said:

After applying CR#315276 and CR#315298, you will be able to install a custom keymap

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

[Sean McCreary 328]

On 9/1/2021 at 11:42 AM, Hook said:

I'm not able to completely follow all of this, but is there anything being proposed here that would allow the / and ? to be remapped off of the P and L keys

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'

[Sean McCreary 328]

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 frustration last month, but I think these changes address the underlying issue.

[Sean McCreary 328]

On 8/28/2021 at 4:44 PM, Sean McCreary said:

On 8/24/2021 at 3:18 PM, VaZso said:

Anyway, I have just found a bug related to the key I wrote an example above.

It has, for normal keystrokes:

/* 24..31 */
KEY_RIGHTALT,    KEY_S,        KEY_Z,        KEY_RESERVED,
KEY_LEFTBRACE,    KEY_MINUS,    KEY_W,        KEY_SEMICOLON,
/* 32..39 */
KEY_BACKSPACE,    KEY_F,        KEY_C,        KEY_RESERVED,
KEY_RIGHTBRACE,    KEY_EQUAL,    KEY_R,        KEY_APOSTROPHE,

Then, for fn keystrokes:
/* 24..31 */
KEY_RIGHTALT,            KEY_S,                KEY_102ND | KF_ALTGR,        KEY_RESERVED,
KEY_RIGHTBRACE | KF_ALTGR,    KEY_MINUS | KF_SHIFT,        KEY_GRAVE,            KEY_MINUS | KF_ALTGR,
/* 32..39 */
KEY_BACKSPACE,            KEY_F,                KEY_C,                KEY_RESERVED,
KEY_RIGHTBRACE | KF_SHIFT,    KEY_EQUAL | KF_SHIFT,        KEY_GRAVE | KF_SHIFT,        KEY_BACKSLASH,

So that is the cause of my scancode change from 26 to 27, the upper one should be KEY_LEFTBRACE instead.

Expand  

"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.

I have verified that each key generates the glyph matching the printed keycap for QWERTZ variant Pro1 devices, as long as in 'Settings -> System -> Languages & Input -> Physical keyboard' *both* 'Advanced settings -> Physical layout' is set to QWERTZ *and* 'Builtin Keyboard -> Choose keyboard layout' is set to German. I will try to find a way to make it easier for users to set the correct configuration to make this less confusing.

Because this seems to be a configuration issue rather than a bug in the default keymap in the keyboard driver, I have abandoned CR#315195.