How to customize the keyboard layout on LineageOS 18.1?

[Slion 1,201]

Also great news it looks like the two Fn keys are not hardwired. I reckon we should be able to give them different mapping.

See that logs sample:

2021-08-25 17:26:08.645 0-0/? I/aw9523b: gpio_keys_gpio_report_event: desc=fn_l code=464 state=1
2021-08-25 17:26:08.796 0-0/? I/aw9523b: gpio_keys_gpio_report_event: desc=fn_l code=464 state=0
2021-08-25 17:26:14.106 0-0/? I/aw9523b: gpio_keys_gpio_report_event: desc=fn_r code=464 state=1
2021-08-25 17:26:14.285 0-0/? I/aw9523b: gpio_keys_gpio_report_event: desc=fn_r code=464 state=0

[VaZso 1,998]

2 minutes ago, Slion said:

Also great news it looks like the two Fn keys are not hardwired. I reckon we should be able to give them different mapping.

It looks good while both can be defined in .kcm file.

However, that would be a bit deeper modification than what I thought to be necessary to at least keep the same functionality what worked in stock OS.

Anyway, it can also be done following the scheme what @tdm has done.
...but would you use the separation of fn keys for anything?

[Slion 1,201]

1 minute ago, VaZso said:

However, that would be a bit deeper modification than what I thought to be necessary to at least keep the same functionality what worked in stock OS.

We are aiming at better than stock 🙂

2 minutes ago, VaZso said:

Anyway, it can also be done following the scheme what @tdm has done.

Exactly just offer more driver level layouts

2 minutes ago, VaZso said:

...but would you use the separation of fn keys for anything?

As I explained above already, I want to do alt+tab using the right Fn which is what Fx Qwerty does for instance. 
Doing alt+tab using the left alt is very unpractical with two thumbs.

[VaZso 1,998]

1 minute ago, Slion said:

As I explained above already, I want to do alt+tab using the right Fn which is what Fx Qwerty does for instance. 
Doing alt+tab using the left alt is very unpractical with two thumbs.

You are right but although it is not practical, it doesn't bother anybody. 🙂

Hehe, I was thinking of I have used it before... err, yes, there is a dedicated alt key there. 😄

Anyway, it takes a while for the repository in docker image to synch / come up.

[Slion 1,201]

2 minutes ago, VaZso said:

You are right but although it is not practical, it doesn't bother anybody

I wondered about that too and I could see only two explanations:

1. Nobody uses alt+tab other than me.
2. I'm just the most perfectionist Pro1 user out there.

5 minutes ago, VaZso said:

Anyway, it takes a while for the repository in docker image to synch / come up.

Yes it does, at least a couple of hours I guess depending on your specs and connection speed.

[VaZso 1,998]

2 minutes ago, Slion said:

Yes it does, at least a couple of hours I guess depending on your specs and connection speed.

Right - connection speed is good but it only uses one core out of eight; okay, virtual eight. 🙂

[claude0001 1,340]

4 hours ago, Slion said:

@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?

No idea, honestly.

I build only once per month and wipe everything in-between as I am limited in disk-space. I had a build fail once due to it running out of space after I did not clean out the previous one ...

A fresh sync-and-build takes 10 ... 12 h for me (3 VM cores, 6 GB RAM), approx. 4 h of which it spends downloading all the stuff (100 Mbit/s).

I honestly do not care about the speed. I start things in the evening and have my image when I wake up in the morning. 🙂

[Rob. S. 1,660]

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

Would it be possible and even sensible to make LOS behave a bit more like stock here, meaning that it would become compatible with FinQwerty/FxQwerty custom layouts? They seem to have worked well for anyone who's used them. I don't have that experience as I never used stock. I was happy, though, with how the US International keymap used to work in LOS 16.1, but I also find 18.1 a bit lacking...

[Slion 1,201]

11 minutes ago, Rob. S. said:

Would it be possible and even sensible to make LOS behave a bit more like stock here, meaning that it would become compatible with FinQwerty/FxQwerty custom layouts?

Yes it will be possible to have a profile matching stock.

[Slion 1,201]

1 hour ago, claude0001 said:

A fresh sync-and-build takes 10 ... 12 h for me (3 VM cores, 6 GB RAM), approx. 4 h of which it spends downloading all the stuff (100 Mbit/s).

Took my i7-7700K workstation about 6h30mn to build over WSL. Excluding repo sync.

Edited August 25, 2021 by Slion

[claude0001 1,340]

22 minutes ago, Slion said:

Took my i7-7700K workstation about 6h30mn to build. Excluding repo sync.

First things first: Congratulations! You have just build your own operating system for your phone. May zombie-apocalypse come, you will be among those who rebuild the world. Time to open a beer or something.

It's interesting that you have a much more powerful CPU than mine but still get similar build-time (all assuming the amount of code is similar from LOS 16 to LOS 18).

Mine is an ageing Core-i3 3220T, with only 3 of its 4 (hyperthreaded) cores assigned to the VM. It is my home server, which I use because its the only machine that runs 24/7 anyway. And, as the server does many other things besides compiling LineageOS, I thought it would be a good idea to leave it one core to fulfill its ... core duties (pun intended) 😄.

I always suspected that I am actually I/O-limited, as my VM sits on a traditional spinning disk. How about you: HDD or SSD?

Edited August 25, 2021 by claude0001

[VaZso 1,998]

50 minutes ago, Rob. S. said:

Would it be possible and even sensible to make LOS behave a bit more like stock here, meaning that it would become compatible with FinQwerty/FxQwerty custom layouts?

Yes, that is why we started pushing a lot of messages here. 🙂

What is why I have started digging into the driver is the practically absolute inability to remap keys pushed together with slant arrow.
I have also found other things in the fn-part of the buttons and I would also suggest to add AltGr function to those buttons even if there are hardcoded layout settings.

If there would be another setting(s) beside QWERTY and QWERTZ then it is possible to build the very same keyboard map what stock OS has (named as QWERTY) and also a non-shifted variant which then will be combatible with PC keyboard on unshifted keyboards of Pro1 (the QWERTZ one and maybe the next QWERY one).

Basically Pro1 in stock OS only had correct scan codes for the shifted QWERTY model. QWERTZ one (which basically more like a standard QWERTY model than the shifted QWERTY) never had correct scan codes as it was also shifted inside.

That is where @tdm's solution made a big correction and also QWERTY and QWERTZ models are providing appropriate scan codes under LineageOS.

Scan codes are the base to identify a key pressed, so that is why standard Android layouts did not work on QWERTZ model.
...and for the very same reason, Finqwerty will work perfectly selecting the very same layout on both QWERTY and QWERTZ models, simply one has to choose the QWERTY model also when it is a QWERTZ in reality. 

[Slion 1,201]

28 minutes ago, claude0001 said:

It's interesting that you have a much more powerful CPU than mine but still get similar build-time (all assuming the amount of code is similar from LOS 16 to LOS 18).

I know. right! 32GB RAM, it was 100% CPU during build so definitely CPU bound, M2 SSD super fast, actually installed it recently to do just that.

Was just adding some logs to the driver and rebuilt, took almost exactly 10mn, not that bad.

[VaZso 1,998]

50 minutes ago, Slion said:

Took my i7-7700K workstation about 6h30mn to build over WSL. Excluding repo sync.

I do it on an i7-6820HQ - however, I gave up the docker solution (it wanted to be too automatic).
Most likely it ran out of free space but it did not write what was the problem, so I have set up an Ubuntu 20.04 in chroot instead.

...then I have restarted it and now I ran out of free space on that partition, so currently I am moving the whole environment to another, khm... SSD.

It needs a plenty of free space.

[Slion 1,201]

1 minute ago, VaZso said:

It needs a plenty of free space.

Got 2TB SSD 🥳 it took quite a hit though with that little venture… 

[VaZso 1,998]

7 minutes ago, Slion said:

Got 2TB SSD 🥳 it took quite a hit though with that little venture… 

Yeah, I am currently copying it from a 1TB SSD to a 2TB SSD but they are not recently installed and the former is also my live backup of important projects in case the latter dies which is a faster M.2 drive.

Also this project has a plenty of files and I don't know if it will completely restart the process or continue it. 🙂

Edited August 25, 2021 by VaZso

[claude0001 1,340]

11 minutes ago, VaZso said:

so I have set up an Ubuntu 20.04 in chroot instead

Do what you think is right for you.

I suggest to just set up a virtual machine with Ubuntu LTS. It works.

Running Ubuntu (or whatever other distribution relying on systemd) in a chroot is not trivial by first priciples of systemd.

Edited August 25, 2021 by claude0001

[VaZso 1,998]

1 minute ago, claude0001 said:

Do what you think is right for you.

I suggest to just set up a virtual machine wit Ubuntu LTS. It works.

Running Ubuntu (or whatever other distribution relying on systemd) in a chroot is not trivial, by first priciples of systemd.

Right, systemd does not make it easier, but build environment is there and basically it works apart from the amount of free space an Android build needs.

[Slion 1,201]

The size of my WSL ext4 partition file is over 250GB after the build. So you may want to make sure you have like 300GB available.

It took like 10mn to rebuild the driver after modification and I could indeed see the logs I added in logcat.

It will be a day long remembered, it has seen the end of Slion's Lineage OS ignorance and will soon see the end of all bugs in keyboard drivers 🥳

Off to bed guys, hope to find the time to tweak that driver tomorrow. That's all that needs to be done.

Edited August 25, 2021 by Slion

[VaZso 1,998]

19 minutes ago, Slion said:

Off to bed guys, hope to find the time to tweak that driver tomorrow. That's all that needs to be done.

What do you want to do?
Adding -ex versions to the UI and appropriate "fn" section(s)?

Do you see how could it be added also to official LineageOS build?

I have almost done the "fn"-variant but stopped yet as wanted to compare it with LineageOS current version - however, the pure one is easy to produce of the current one I have.
Just asking because it is a particular (what is the appropriate word?) work and not really an interesting part, but it should be correct in order to work well...

[Slion 1,201]

36 minutes ago, VaZso said:

What do you want to do?

I'm not exactly sure yet but not that much really.

Add a new set of layouts that would:

- Unmask the Fn keys so that custom layouts can remap them.
- Decouple the Fn keys, I guess they will be mapped to so called left meta and right meta.
- Look at why custom keymap is not working as it should.
- Fix other bugs if any.

Now that I understand that the qwertz driver layout is there to fix the scan code for compatibility with standard layout I'm not sure it makes sense to provide drivers layout compatible with stock and FinQwerty.

Edited August 25, 2021 by Slion

[VaZso 1,998]

3 hours ago, Slion said:

Add a new set of layouts that would:

So you mean QWERTY-ex and QWERTZ-ex as you mentioned earlier.

3 hours ago, Slion said:

- Unmask the Fn keys so that custom layouts can remap them.

That is really easy if you could add -ex layouts above - I didn't have a chance to look at UI side and also testing would not be easy for me currently but at driver side it is easy.

3 hours ago, Slion said:

- Decouple the Fn keys, I guess they will be mapped to so called left meta and right meta.

I don't feel it is necessary and it would also need some refactoring of the code - it can be done but higher effort for less value.
I also don't know if meta is available to use in .kcm file but I suspect it is, however, it would lose AltGr functionality which means international layouts AltGr part would also be skipped that way.

So for international layout compatibility, it is also better to keep slant arrow as AltGr and logically wired together for easy access of the AltGr+right side of the keyboard.

So for general compatibility, AltGr was a good decision, it is better to remain there and also higher amount of modification is not needed - the problem lies in the "fn" layer of button handling where an additional AltGr bit should be set for all keys, that is the key for a remappable layout.

3 hours ago, Slion said:

- Look at why custom keymap is not working as it should.

See above, it works well where AltGr bit is also set in keymap on "fn" array - I have checked it.

3 hours ago, Slion said:

- Fix other bugs if any.

Apart of the "fn" array, I think there is no need of higher modification.

If you could add QWERTY-ex and QWERTZ-ex or similar items to the UI, the driver would only need a few lines of additional rows and two (or logically correct way four) additional set of arrays correctly set.

That's all we need to have a remappable keyboard.

3 hours ago, Slion said:

Now that I understand that the qwertz driver layout is there to fix the scan code for compatibility with standard layout I'm not sure it makes sense to provide drivers layout compatible with stock and FinQwerty.

What it really does is to assign correct scan code representation for their respective keys.
As far as I know, stock OS has appropriate scan codes for "shifted" layout which means non-alfanumeric keys are placed somewhat "randomly", so that way key codes are mixed - so by definition it should be same as in stock OS, thus, it is compatible (Edit: apart from "fn" key became AltGr so yes, Finqwerty may also need another layout variant).

As of the QWERTZ layout, all keys are in place the same way as in a standard QWERTY layout, so incompatible with stock OS scancodes (as it only had one, the shifted) but the most standard one - logically it should has been the main and the shifted variant is the modified one, also it seems they drop shifted keys in Pro1-X, so this will be really the standard.

Also, that is why I told naming convention of "QWERTZ" is a bit wrong as Pro1-X layout will be "QWERTZ" the same way as it is being unshifted, but it will have standard QWERTY layout which will be misleading.
Maybe it is better to call them as "Standard" and "Shifted" - I am speaking about the additional selections if you can do it.

Edited August 26, 2021 by VaZso

[VaZso 1,998]

44 minutes ago, Slion said:

- Unmask the Fn keys so that custom layouts can remap them.

Maybe one way it would be a good compromise... if it would also add AltGr (as currently although it practically does not use it) and also meta-left and meta-right, so general AltGr functionality would also work while they could also be defined specifically.

...but I still think we don't really need it, alt+tab may be used on both of them and it would need higher amount of modification.... for practical use, it is unnecessary to do it.

[Slion 1,201]

On 8/24/2021 at 5:54 PM, Rob. S. said:

I'm using the "English (US), international style" layout for the physical keyboard (QWERTY), and I've attached what I get from it (made with Softmaker Office for Android on the Pro1) with the help of the Sym key when (as in most if not all browsers) I have no access to the long-press special key selection popup. Unfortunately, while this key map covers much including everything the German language uses, I already can see it does not even remotely cover the French accents. 

 

keys.pdf 102.85 kB · 7 downloads

Though you can get all the French characters you need using diacritrical dead keys. Now I'm starting to understand the amazing work that @tdm has done with those drivers by making them compatible with standard layouts.

[Slion 1,201]

5 hours ago, VaZso said:

Also, that is why I told naming convention of "QWERTZ" is a bit wrong as Pro1-X layout will be "QWERTZ" the same way as it is being unshifted, but it will have standard QWERTY layout which will be misleading.
Maybe it is better to call them as "Standard" and "Shifted" - I am speaking about the additional selections if you can do it.

This driver is not for Pro1X, just for Pro1.