How to customize the keyboard layout on LineageOS 18.1?

[VaZso 1,998]

Just now, Slion said:

@VaZso You lost me. Which problem are you trying to solve?

I could not redefine my layout because of the typo above and these arrays should be checked also for other typos.

So when I press together slant arrow+"[" character, its scancode changes from 26 to 27 and the above typo is the reason of that (so it behaves like if I was pressing slant arrow+"]" character).

It definitively has to be corrected in keyboard driver while I also would like to check for other typos.

As part of it, I don't understand why it uses KF_SHIFT and KF_ALTGR flags in "fn"-related array mixed together which I also would like to check if it may be related of the multiple keypresses problem shown by the application I used for testing.

The above post was an interpretation what the keyboard driver does and during that, I have found a typo in physical layout handling.

[VaZso 1,998]

Okay, currently I am only investigated QWERTZ layout, but its FN section is completely messed up.

Only those characters are working which are in appropriate places and OR-ed by KF_ALTGR
There are mistakes inside, also KEY9 (for example) character has double places inside, so it should be totally corrected.

For characters which use KEY | KF_ALTGR there, I see the correct scancodes and also 100 which is a press of AltGr, so that part is totally fine, only the FN section should be corrected.

I think @tdm was really tired when he filled that table in.

Edited August 24, 2021 by VaZso

[claude0001 1,340]

@VaZso, I'm also lost.

So, what you say is when you type "slantarrow + i" on your QWERTZ keyboard, you get a "]" instead of a "[" (as yellow-labeled on the keycap)?

That's not the case in LOS 16.0. I can type all yellow symbols as printed on the keyboard. So better do not blame @tdm too much.

Edited August 24, 2021 by claude0001

[VaZso 1,998]

1 minute ago, claude0001 said:

I'm also lost.

So, what you say is when you type "slantarrow + i" on your QWERTZ keyboard, you get a "]" instead of a "[" (as yellow-labeled on the keycap)?

That's not the case in LOS 16.0. I can type all yellow symbols as printed on the keyboard. So better do not blame @tdm.

I am not tried to blame @tdm but I have found the code linked earlier has some typos, basically fn-related arrays are not correct. There are some keys exist at two places and AltGr flag is missing on most of them and that made my custom layout unable to work.

This kind of a typo is definitively caused by a tired programmer maybe at a very late hour of programming and definitively not a bad programmer.

Also the driver as a whole is well written.

Currently I try to do an fn-version of array based on the non-fn version which I think is absolutely correct.

One thing what I currently ran into is ESC-->Back and UP-->PgUP, Down-->PgDown, Left-->Home and Right-->End keystrokes are hardcoded there and not soft-coded what I have remembered (as a setting).
However, they may also contain AltGr flag - earlier I did the very same modification (on stock) but based on fn+arrow in a .kcm file.

Also there are other hardcoded characters which should not be there as it causes national layouts to be broken.

So, I am not blaming @tdm but I currently try to rebuild that array then I will send to him for checking and if he may update it in the source.

Anyway, it may or may not exists in earlier version, but I may try to give you an example.
Do you have QWERTY variant?

[claude0001 1,340]

1 minute ago, VaZso said:

Do you have QWERTY variant?

No, I have QWERTZ. And when I hit "[" ("slantedarrow + i") on the keyboard, I indeed get a "[" on screen. I repeat: does this not work for you?

[VaZso 1,998]

9 minutes ago, claude0001 said:

No, I have QWERTZ. And when I hit "[" ("slantedarrow + i") on the keyboard, I indeed get a "[" on screen. I repeat: does this not work for you?

Okay, so I was speaking about QWERTY layout on QWERTZ variant (so US standard layout as QWERTZ is much closer to it than the shifted QWERTY).

So the characters in question are "Ü" and "+" and its normal representation is good, but fn+"Ü" representation will give you fn+"+" representation.

It is only one example, there are also other typos, most of them are exists twice after each other in the array.
...like "KEY_0" in the fn-part of "KEY_P", so fn+P will give you what fn+0 should give.

I may not found this issue if I was not trying to redefine the keyboard as most of the keys seem to work well, but the array which contains the key representation of "fn" pressed states is not filled correctly.

Edit:
Please check it with "KeyEvent Display".
It can be downloaded from Play store.

You should see the "scanCode" of a specific key, then if you press slant arrow+specific key, it should display the very same "scanCode" together with a "scanCode" of 100.

That is the easiest way to check.

For arrows and ESC, it is there for a reason but otherwise it should behave like this.

Edited August 24, 2021 by VaZso

[claude0001 1,340]

14 minutes ago, VaZso said:

I was speaking about QWERTY layout on QWERTZ variant

I maybe too tired to understand the motivation behind this.

But I do get now you discovered a bug which is not apparent if one uses QWERTZ-layout-on-QWERTZ-variant and/or does not use custom keymaps?

If so, the bug should be present since LOS 16 indeed, as the respective code in qx1000.c looks identical.

[VaZso 1,998]

It seems only QWERTZ variant has mistakes (I have looked into it basically because I use that one) but QWERTY variant also does not add KF_ALTGR flag which makes impossible them to be remapped (not appears as ralt in which could be used in .kcm files).

There are also the following keys hardwired in the driver:
- For QWERTY: 

• KEY_P --> KEY_SLASH
• KEY_L --> KEY_SLASH --> I think this one wanted to be a question mark which may be modified in a later revision (I remember it used to be a problem for some users)

- For QWERTZ:

• KEY_W --> KEY_GRAVE
• KEY_APOSTROPHE --> KEY_BACKSLASH
• KEY_L --> KEY_BACKSLASH

For QWERTZ variant, it may be messed up a bit, I think there was an updated driver.
KEY_L became "|"

However, this kind of hardwiring was a really bad idea at driver level preventing the ability to remap those keys.
There is a config option to enable F1-F12, why wasn't it possible to do it the same way instead of hardwiring them?

I am also getting really tired because it is too late here.
I would need the updated driver for the current version of hardcoded keys but I am starting to understand why @Slionwrote the quote below:

8 hours ago, Slion said:

However some of it gave me an idea.
It looks like ATM we have like two profiles QWERTY and QWERTZ.
I wonder if we could modify the driver to add more profiles QWERTY and QWERTZ variant that would be compatibly with stock so that FinQwerty and other mods would work the same. I would probably also add another profile that's improved on stock.

Apart of the not perfectly filled QWERTZ array, it would be better to also have a pure QWERTZ and QWERTY setting of the system.
Simply because hardwiring prevents the ability of proper remapping the keys and even standard layouts will lose the hardwired key's "fn" part.

I could definitively do the driver part of it but unsure if I can do the high level part.
@Slion, could you do the high level part of it (may you have experience in Android programming)?

It would be better as hardwired part will not be perfect ever for remapping.
An even better solution would be to add a similar option like enabling F1..F12 for fn+numbers - that is not hardcoded.

I will download the sources tomorrow I think (it is 2:30 again here).

[VaZso 1,998]

1 hour ago, claude0001 said:

But I do get now you discovered a bug which is not apparent if one uses QWERTZ-layout-on-QWERTZ-variant and/or does not use custom keymaps?

Yes, there is a "bug" in QWERTZ variant as one value was mistyped and some of them exist twice in a row.
Another problem is the missing AltGr flag on these keys (it also applies on QWERTY variant) and that is why these keys are basically non-remappable.

My basic problem is I used a custom-made keyboard mapping on my Pro1 under stock OS and I have recently moved to LineageOS and realized I have no chance to setup the very same layout I used since I have my Pro1 as it has the problems above.

On top of that, there is some kind of hardcoding which is another problem but also affects remapping.
However, I don't know if characters like a question mark is remappable.
If so, then there is a workaround and only the above written code should be modified to have a chance for a working solution, so QWERTZ layout corrected + supplemented and QWERTY layout supplemented.

This case the workaround would be to define the "fn/altgr" portion of desired key to the hardcoded key's setting instead of the pressed key - if that works, remapping is possible even if only this slight modification happens.

[Slion 1,201]

9 hours ago, VaZso said:

when I press together slant arrow+"[" character, its scancode changes from 26 to 27 and the above typo is the reason of that (so it behaves like if I was pressing slant arrow+"]" character).

I can reproduce your issue on qwertz layout with qwerty keyboard.
Sounds like a mapping bug in that array indeed.
It just goes to show how little testing LOS as had on Pro1.

You should open a bug on GitLab about that one issue.
Keep it focused and short.

Edited August 25, 2021 by Slion

[Slion 1,201]

7 hours ago, claude0001 said:

But I do get now you discovered a bug which is not apparent if one uses QWERTZ-layout-on-QWERTZ-variant and/or does not use custom keymaps?

Is it not? I don't get why it would not. Not much of a bug then after all...

[Slion 1,201]

@VaZso Some keys are hardwired but it seems like you mean more like hardcoded.

[claude0001 1,340]

1 hour ago, Slion said:

Is it not? I don't get why it would not. Not much of a bug then after all...

I most probably simply do not understand enough about how re-mapping works since I have never done that.

But from a dummy user perspective: When (on LOS 16, qwertz variant with qwertz layout) I type "slantedarrow + i" (which is the key labelled "[" in yellow), I indeed obtain a "[" character on screen. According to @VaZso's research, I would expect to get the neighboring "]", but I don't.

In Android Apps, all yellow-symbol keys work as expected for me. That said, I have had issues forwarding those to remote servers using many VNC client apps. So maybe at some level there are bugs, even with my config, which is why I follow this thread with much attention now ... Thanks for digging.

I remember that @tdm worked on that keyboard driver for quite some time, e.g. in order to enhance the number of simultaneously possible keypresses with respect to stock (important for flexible key assignment in gaming). It is a pity he no longer seems to follow these threads as there may be a risk we regress if we start to change things on the driver level without knowing the full story of how things came about.  

 

[Slion 1,201]

14 minutes ago, claude0001 said:

I most probably simply do not understand enough about how re-mapping works since I have never done that.

I have a feeling @VaZso is trying to get qwertz keymap to work with a qwerty keyboard and that somehow won't work as he would expect but that's actually not a bug. You are saying it works fine on your qwertz so I think we are good there.

[Slion 1,201]

8 hours ago, VaZso said:

I could definitively do the driver part of it but unsure if I can do the high level part.
@Slion, could you do the high level part of it (may you have experience in Android programming)?

I'm currently busy setting up my Lineage OS build environment. I'm more then happy to take on your feedback. And yes I still think the way forward is to provide more layout in the kernel so that there is something for everyone including crazy remappers like you and me.

Here are the layout I envision, keep the current ones with silent Fn:

qwerty
qwertz

Improved layout with non silent Fn and possibly Meta key, thus providing application level with as much modifiers as possible:

qwerty-ex
qwertz-ex
 

@EskeRahn @Waxberry or @Erik Do you recall which keys are actually hardwired?

We have 66 keys hooked up to a 64 slots switch board so to say. Therefore at least 2 pairs of keys are hardwire.
Hopefully it is exactly 2 pairs.

Was it the Ctrls or the Shifts or the Fns? Hopefully one of those 3 pairs of keys is not hardwired which one was it?
I'm hopping that's the Fns. I guess a closer look at the driver code should tell us though.

Again one of my main motivation for improving our keyboard driver is to notably enable alt+tab using the right Fn which was doable on stock using some clever/twisted mapping.

Edited August 25, 2021 by Slion

[VaZso 1,998]

3 hours ago, claude0001 said:

I most probably simply do not understand enough about how re-mapping works since I have never done that.

It works like this (in .kcm file):

key W {
    label:                              'W'
    base:                               'w'
    shift, capslock:                    'W'
    ralt:                               'm'
    meta:                               'p'
    alt:                                '\u0302'
    fn:                                 '|'
    fn+shift, ctrl+fn, fn+capslock:     '\u00c5'
}

You may define what key combinations should do what in a similar combinations like above (the above is just an example and not more).

3 hours ago, claude0001 said:

When (on LOS 16, qwertz variant with qwertz layout) I type "slantedarrow + i" (which is the key labelled "[" in yellow), I indeed obtain a "[" character on screen. According to @VaZso's research, I would expect to get the neighboring "]", but I don't.

I was mentioning the keyboard if it would not has anything written on it but would behaves like a QWERTY one to name the position of a key, sorry.
So the keys I was referring to are "Ü" and "+", so second row 12th and 13h key and 12th becomes 13th on pressing together with "FN".

3 hours ago, claude0001 said:

In Android Apps, all yellow-symbol keys work as expected for me.

I don't have this feeling anyway on QWERTZ variant using English layout currently, however, it could be done by remapping which is not supported.

3 hours ago, claude0001 said:

I remember that @tdm worked on that keyboard driver for quite some time, e.g. in order to enhance the number of simultaneously possible keypresses with respect to stock (...) It is a pity he no longer seems to follow these threads as there may be a risk we regress if we start to change things on the driver level without knowing the full story of how things came about.  

That work is there, the code is clean and it is well readable, also it was written in a way it has two sets of keyboard mapping:

• one for normal keypresses
• one for keypresses together with FN

Also, these sets of the keys can be "loaded" based on a setting in Android where you can choose you have QWERTZ or QWERTY variant of Pro1.

So basically it can also be extended (for other variants) easily without modifications of the actual handling code.
This kind of regression what you afraid of practically does not exists.
Also that makes possible to include other physical layouts later what users also would like to see on Pro1's physical layout, so, also adding them is not complicated at all.

At driver level, remapping basically is not at a right place and that is why it prevents doing this at higher level.
I don't know why it wasn't done similarly like F1...F12 row (maybe because it would need separate settings for QWERTZ and QWERTY variant), but loading another keysets for different variants is the simplest and less "risky" modification what can be done.

[VaZso 1,998]

3 hours ago, Slion said:

I have a feeling @VaZso is trying to get qwertz keymap to work with a qwerty keyboard and that somehow won't work as he would expect but that's actually not a bug.

I didn't say it is a bug.
Anyway, I have tried to get QWERTZ variant to work with QWERTY keymap where I can also reach characters which is often used in my language and slant arrow was a perfect key to reach them as it exists on both sides.
If it is an intended work of it, then it is a regression.

3 hours ago, Slion said:

Here are the layout I envision, keep the current ones with silent Fn:

Improved layout with non silent Fn and possibly Meta key, thus providing application level with as much modifiers as possible:

It would be perfect and -ex variants should has the raw layout, without any remappings at driver level.

However, the name of QWERTY can be a bit misleading if F(x)tec will publish non-shifted physical layout together with Pro1-X.
Basically it is all about SHIFTED and NON-SHIFTED layout as historically every international layouts use the standard key codes. So if one does not look at the keyboard texts, it will behave as a non-shifted, standard QWERTY layout.

Currently it is not a problem, but it will be strange if non-shifted QWERTY users should choose QWERTZ for the question what layout they have...

Hardcoded modifications are another question...

3 hours ago, Slion said:

@EskeRahn @Waxberry or @Erik Do you recall which keys are actually hardwired?

We have 66 keys hooked up to a 64 slots switch board so to say. Therefore at least 2 pairs of keys are hardwire.
Hopefully it is exactly 2 pairs.

As far as I know, these are two shifts and the two slant arrows.
So it can not determine which slant arrow is pressed.

I will try to build an environment and get the actual version of driver code later the day.

36 minutes ago, Slion said:

I'll make another attempt with WSL this time from an actual ext4 file system rather than from a Windows mount.
Apparently that should work:

It would be definitively much easier to do it on a virtual machine. 🙂

...but yes, the basic problem was filesystems on Windows do not distinguish capital and non-capital letters but filesystems on Linux do. I don't know how well Windows work on an ext4 filesystem currently, but it may have problems...

It seems to be better working on a system which is generally case-sensitive. 🙂

[Noob 158]

@VaZso there's also this Docker image you can use.  It didn't work for me in Windows 7, but worked in Linux and I think the Docker experience is much better if you're on W10, which you must be if you're using WSL.

[Slion 1,201]

53 minutes ago, VaZso said:

As far as I know, these are two shifts and the two slant arrows.

That's what I feared… ho well we'll make do with that then.

[Slion 1,201]

3 minutes ago, Noob said:

@VaZso there's also this Docker image you can use.  It didn't work for me in Windows 7, but worked in Linux and I think the Docker experience is much better if you're on W10, which you must be if you're using WSL.

Interesting, complete with a guide to enable OTA... 

[Slion 1,201]

1 hour ago, VaZso said:

As far as I know, these are two shifts and the two slant arrows.
So it can not determine which slant arrow is pressed.

Actually the driver source code it says:

 *  Note that there are two each of the shift, ctrl, and alt keys, but

 *  each pair are driven by a single gpio.  Thus, left and right cannot

 *  be distinguished for these keys.

[VaZso 1,998]

4 minutes ago, Slion said:

That's what I feared… ho well we'll make do with that then.

Seriously it worked really well for me under stock OS - I took the project what @Anssi Hannula has created (finqwerty), removed all the layouts from it and only installed two custom layouts for me, but only one of them was in use on my Pro1.
That was a custom build renamed to not conflict with original software which was also installed.

Anyway, these kinds of custom layouts do not consume power resources like a special application would, these layouts are reachable in the same way like original layouts - absolutely a perfect solution which does not need root access but exactly works like the same way.

So this kind of solution does not work currently on LineageOS which is why I called it regression above.

[Slion 1,201]

2 minutes ago, VaZso said:

Seriously it worked really well for me under stock OS - I took the project what @Anssi Hannula has created (finqwerty), removed all the layouts from it and only installed two custom layouts for me, but only one of them was in use on my Pro1.

Did the same:

https://slions.net/resources/fx-qwerty.7/

[VaZso 1,998]

17 minutes ago, Slion said:

Actually the driver source code it says:

 *  Note that there are two each of the shift, ctrl, and alt keys, but

 *  each pair are driven by a single gpio.  Thus, left and right cannot

 *  be distinguished for these keys.

It may happen also ctrl buttons are wired together, but it isn't a huge problem compared to loosing all of the FN functionality.
...and that is a hardware limitation which can not be improved like software limitation. 🙂

Edit:
Anyway, there are reserved locations in keyboard driver (I mean in the buttons representation), I don't know what they are exactly - it would be good to have the hardware wiring to find it out easily or to see why they are in the row.

Edited August 25, 2021 by VaZso

[Slion 1,201]

My Lineage OS build has been running for some time already and so far so good, I reckon it should complete.

I was investigating how to debug that keyboard kernel driver and it seems pretty easy.
It turns out all those printk calls land in logcat, it's therefore easy to inspect them in Android Studio for instance and debug the driver. Seems like they are all prefixed with aw9523b so you can use that to filter your logs.

That means that providing that my build works and that I can deploy it I reckon I should be able to tweak our keyboard driver.

@claude0001 I have one concern about the speed of incremental builds though. Say if change just that one C file how long does it take to rebuild?

Edited August 25, 2021 by Slion