Jump to content

How to customize the keyboard layout on LineageOS 18.1?


Recommended Posts

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.

  • Thanks 4
Link to post
Share on other sites
  • Replies 294
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

tdm added a feature to his keyboard driver that allows the user to specify a custom keyboard map. Unfortunately there is no documentation (other than the source code), but you should be able to remap

I have made a lot of keyboard-related changes on the code, now I will try to summarize them. Also, I have tried to reach a state what probably all of us may find useful and also original working

I recently migrated to LineageOS from stock, where I was a happy FinQWERTY user. After seeing it was broken and finding out in the forums that FinQWERTY is expected not to work, I've been crawling all

Posted Images

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. 

  • Like 2
  • Thanks 1
Link to post
Share on other sites
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?

Link to post
Share on other sites
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 by Slion
Link to post
Share on other sites
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!

  • Thanks 2
Link to post
Share on other sites
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.

  • Like 1
Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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)?

Link to post
Share on other sites
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,

Link to post
Share on other sites
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.

  • Thanks 1
Link to post
Share on other sites
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.

  • Like 1
Link to post
Share on other sites
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.

  • Like 1
Link to post
Share on other sites
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 by VaZso
Link to post
Share on other sites
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.

  • Like 1
Link to post
Share on other sites
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 ūüôā

Link to post
Share on other sites
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.

  • Thanks 1
Link to post
Share on other sites
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.

Link to post
Share on other sites
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

 

  • Like 1
  • Thanks 1
Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

  • Like 1
  • Thanks 2
Link to post
Share on other sites
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

  • Like 1
  • Thanks 2
Link to post
Share on other sites
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'

  • Thanks 1
Link to post
Share on other sites

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.

  • Thanks 4
Link to post
Share on other sites
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.

  • Thanks 3
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Terms