How to customize the keyboard layout on LineageOS 18.1?

[Slion 1,201]

@VaZso Thanks for you comments.

What do you want to modify/fix in the drivers?
You do know that AltGr is the Sym key?
If you need an extra layer of modifier you should be able to remap the Home key AKA FxTec key to a meta modifier or whichever one works for you.

Edited August 26, 2021 by Slion

[Slion 1,201]

Right now here is what I'm thinking we should be doing:

- Fn keys remain silent.
- Special feature so that right Fn can be used to alt+tab and as Fn too.
- Maybe add extra functionalities to Fn layer optionally or default.

[Slion 1,201]

6 hours ago, VaZso said:

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

You misunderstand me. I was talking about the custom scancode keymap from keyboard advanced settings, not the kcm files.

[Slion 1,201]

9 hours ago, claude0001 said:

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.

Nothing new here I was doing that back in 99 already 😁😇

[VaZso 1,998]

4 hours ago, Slion said:

You do know that AltGr is the Sym key?

I don't think so, I could not see it working that way and AltGr is designed to be something else.

Basically that is the very same keypress as "right alt" simply they needed a special key on international keyboards (back in standars PC) and as a result, they has renamed right alt to AltGr which became a "special shift" for extra characters the layout not has as standard.

For example, if you connect a keyboard to a PC which has Hungarian layout but your OS was set to English/USA, AltGr will be right alt. If you connect a standard (USA) keyboard but OS is set to Hungarian layout, right alt will be AltGr.
What is written on that key does not matter, it has a scan code and the OS interprets the way it needs.
Scancode has not changed, keyboards remained exactly the same inside but they printed different letters on them.
So, right Alt is still there, it's name is AltGr in international keyboards.

Sorry for writing the above detailed, it seemed you may not know the background of it.

If you look into the driver code, it clearly uses AltGr for "FN" keypress as per defined in KEY_RIGHTALT macro.

if ((g_logical_modifiers & KF_ALTGR) && !(g_physical_modifiers & KF_ALTGR)) {
	printk(KERN_INFO "aw9523b: release logical altgr\n");
	input_report_key(aw9523b_input_dev, KEY_RIGHTALT, 0);
	input_sync(aw9523b_input_dev);
	g_logical_modifiers &= ~KF_ALTGR;
}

 

4 hours ago, Slion said:

What do you want to modify/fix in the drivers?

If it has a mode where it works the same way as a PC keyboard, then stock keyboard layouts (which Android has built-in) would work the way it was intended and also all keys would be redefinable.

If that happen, I could do my custom keyboard just like on stock OS.
What I would like to modify is the "static const u16 qwertz_fn_keys[AW9523_NR_KEYS] = {"-like array which contain keypresses while slant arrow is pressed.

If you could do another layout setting, this may be put there.

4 hours ago, Slion said:

If you need an extra layer of modifier you should be able to remap the Home key AKA FxTec key to a meta modifier or whichever one works for you.

I don't really need extra modifier key, I simply would like to use my keyboard which I currently has a highly limited work what is practically unusable for me.

Exposing FxTec key to meta would be a plus anyway, I am not against it...

4 hours ago, Slion said:

Right now here is what I'm thinking we should be doing:

- Fn keys remain silent.

Please no.
That is the main purpose of AltGr which is exactly right alt which is also set the correct way in driver, simply it needs to be also applied in "fn" array.

4 hours ago, Slion said:

- Special feature so that right Fn can be used to alt+tab and as Fn too.

You can apply meta and AltGr together which is not a problem.
If there is right and left meta available (not checked), then you may set these modifiers to both slant arrows.

4 hours ago, Slion said:

You misunderstand me. I was talking about the custom scancode keymap from keyboard advanced settings, not the kcm files.

You have also misunderstood me (see above).
I am speaking about keymap in driver level which should be correct to use custom keymap at higher level.

It would be an easy modification once a similar setting like "QWERTY" and "QWERTZ" could be solved.

Edited August 26, 2021 by VaZso

[Slion 1,201]

16 minutes ago, VaZso said:

I don't think so, I could not see it working that way and AltGr is designed to be something else.

Sorry for writing the above detailed, it seemed you may not know the background of it.

I do understand AltGr, I use a French keyboard 🙂 

RightAlt  is AltGr and is mapped to Sym in our driver, key index 24 in the default keymap arrays.

You can try it together with US international layout on your QWERTY keyboard it works as it should.

Edited August 26, 2021 by Slion

[Slion 1,201]

27 minutes ago, VaZso said:

If you look into the driver code, it clearly uses AltGr for "FN" keypress as per defined in KEY_RIGHTALT macro.

if ((g_logical_modifiers & KF_ALTGR) && !(g_physical_modifiers & KF_ALTGR)) {
	printk(KERN_INFO "aw9523b: release logical altgr\n");
	input_report_key(aw9523b_input_dev, KEY_RIGHTALT, 0);
	input_sync(aw9523b_input_dev);
	g_logical_modifiers &= ~KF_ALTGR;
}

 

No it does not, I'm not sure how you are reading this from that code sample. That code is responsible for releasing a forced AltGr modifier. Modifiers are said to be forced when they are applied by the driver as part of the defined keymap as opposed to being applied because the user actually pushed that modifier key. This driver can generate logical modifiers input that do not correspond to physical modifiers input. I believe this was done for improved app and layout compatibility and mostly used by the QWERTZ keymap.

So when you press Fn you will never get a key event at the application level. Only when you press another key together with Fn will you get the key event possibly nested within logical modifiers key event depending of your keymap.

Edited August 26, 2021 by Slion

[Slion 1,201]

I already have a first draft of that nf+tab as alt+tab feature.
It should have no impact on the rest of the driver functionality.
Only thing it does is let you use fn+tab exactly as alt+tab.

[VaZso 1,998]

11 minutes ago, Slion said:

No it does not, I'm not sure how you are reading this from that code sample. That code is responsible for releasing a forced AltGr modifier. Modifiers are said to be forced when they are applied by the driver as part of the defined keymap as opposed to being applied because the user actually pushed that modifier key. This driver can generate logical modifiers input that do not correspond to physical modifiers input. I believe this was done for improved app and layout compatibility and mostly used by the QWERTZ keymap.

Right, the following modifiers it handles:

• KEY_LEFTSHIFT
• KEY_LEFTCTRL
• KEY_LEFTALT
• KEY_RIGHTALT
• KEY_CAPSLOCK

Yes, it can generate logical modifiers and if KF_ALTGR flag is applied in "fn" array, it will send KEY_RIGHTALT which would make possible of higher level layout defining.

That is what I need, that is needed for a solution like Finqwerty would work and that is what national layouts may use.

Alt+tab is one thing but the inability of redefining the keyboard is a much higher problem I think, as for me, basically the keyboard is UNUSABLE for me this way.

I understand why it is there and layout may has the yellow keys respective values, however, that is broken for QWERTZ layout - that is one thing.
It is there for a reason to work on top of every layouts Android has.

Otherwise, doing this on a driver level makes impossible to use any other custom layouts and that is the problem.
It worked _really well_ on stock OS and it would work absolutely well here, but wiring something in the code which can not be modified by the user makes the solution restricted, thus, unusable for any non-standard solutions - which I mean the standard way of doing something different.

 

[VaZso 1,998]

Anyway, if it remain there, I will move back to stock OS as I wold like to USE my device and I currently CANT!

Driver is a low-level thing and it should not prevent doing higher level API to work!

 

Also I am feeling to give up and may even buy another device if it remains unusable.
The only reason I have it is the keyboard! Sorry, I feel enough and being nervous being alone.

Edited August 26, 2021 by VaZso

[claude0001 1,341]

21 minutes ago, VaZso said:

Sorry, I feel enough and being nervous being alone.

As far as I know, the driver in Lineage has been made different from the one in Stock for a purpose. And it has worked quite well for many people across 3 Lineage releases now. You seem to have a very specific use-case (that I still do not understand), which is totally fine. But please do not blame everyone else for being happy with things as they are.

If you propose changes, please do not look only at your special case. Not that I understand much of the discussion, but the suggestion of @Slionto add one or more additional keyboard profiles to fulfill your needs seems reasonable and would probably get accepted upstream.

If you want to change the driver in a way to break the current behaviour, you are always free to make your local build of LOS just for yourself.

Edited August 26, 2021 by claude0001

[VaZso 1,998]

7 minutes ago, claude0001 said:

As far as I know, the driver in Lineage has been made different from the one in Stock for a purpose.

Yes, stock OS did not distinguish QWERTY and QWERTZ and I think also the handling of keypresses were worse.

8 minutes ago, claude0001 said:

And it has worked quite well for many people across 3 Lineage releases now.

...and it will continue to work anyway even if it would be usable for others.

9 minutes ago, claude0001 said:

You seem to have a very specific use-case (that I still do not understand), which is totally fine.

I don't know how specific it is, but the use case:

• Pro1 has a relatively few amount of keys
• My language has a lot of keys which adds to English alphabets
• I can reach all characters instantly by using both slant arrows
• Current driver does not allow using slant arrows for this purpose but mostly could be added while normal use case does not change

It seemed @Slion may also able to include another option in special system configuration near QWERTZ and QWERTY mode which would make a separate keymap which is remappable the same way as in stock was.

15 minutes ago, claude0001 said:

If you propose changes, please do not look only at your special case.

What I have told is not a special thing, that is the standard way a keyboard work on any OS - and it would allow high-level things to do.

Driver is basically a low-level code which means it handles things close to the hardware itself and provide functions/data to an upper level.

At upper levels, there are keyboard handling code of the OS itself - it doesn't interested in what generates the data, it will interpret it and do appropriate things.
That is what current driver code does not implement - it can, but did not set up that way.

So this "special" case means a general keyboard behaviour with all of its advantages.

19 minutes ago, claude0001 said:

If you want to change the driver in a way to break the current behaviour, you are always free to make your local build of LOS just for yourself.

Right, but that way lots of benefit having an official LineageOS support would be lost and it would also mean it should be maintained myself while adding appropriate methods at driver level would make it universal - huge difference.

I had to go for a walk anyway but I am still sad.

[Slion 1,201]

@VaZso I was like you when I first looked at the LOS keyboard driver seeing how it was not compatible with stock. However I see now that stock was really broken and that's why solutions like FinQwerty was needed. Now LOS driver fixed that by being compatible with Android built-in layouts so solution like FinQwerty are not so obviously needed now.

Which hardware keyboard do you have? Qwerty or Qwertz?

Which keymap are you trying to use? Qwerty or Qwertz?

Which layout do you want to use? US international?

Which languages do you want to type in?

Edited August 26, 2021 by Slion

[Slion 1,201]

Does anyone knows why alt does not bring up the emoji keyboard on LOS like it did on stock?

[VaZso 1,998]

15 minutes ago, Slion said:

However I see now that stock was really broken and that's why solutions like FinQwerty was needed.

In stock, I think they did it the simplest way.
FinQwerty was mostly needed because QWERTZ layout did not have their keys in appropriate positions as it was also provide the same keycodes as shifted variant - it did not have separate settings.

So it was really bad on QWERTZ units but I think it was good at QWERTY units.

15 minutes ago, Slion said:

Now LOS driver fixed that by being compatible with Android built-in layouts so solution like FinQwerty are not so obviously needed now.

Right, but that is not compatible for AltGr functions as it does not generate it and not even generates "FN" function which could be corrected with the help of a solution like Finqwerty.

15 minutes ago, Slion said:

Which hardware keyboard do you have? Qwerty or Qwertz?

QWERTZ

15 minutes ago, Slion said:

Which keymap are you trying to use? Qwerty or Qwertz?

Standard QWERTY (non-shifted naturally) but also supplemented with national characters for me.
These are: áéíóöőúüű and their capital versions ÁÉÍÓÖŐÚÜŰ in convenient places mostly out of normal alphabet places.
...but for example, there is no key for "í" so I have defined is as slant arrow+Q - that key (í,Í) would be either near enter key (so after " J ", " K ", " L ", " ; " " ' " or before " Z ", " X ", " C " - so Pro1 does not have it; on English keyboard, it would be " \ " or " | ").

Edited August 26, 2021 by VaZso

[Slion 1,201]

5 minutes ago, VaZso said:

Right, but that is not compatible for AltGr functions as it does not generate it and not even generates "FN" function which could be corrected with the help of a solution like Finqwerty

Again AltGr is Sym

[claude0001 1,341]

15 minutes ago, Slion said:

Does anyone knows why alt does not bring up the emoji keyboard on LOS like it did on stock?

That works on LOS 16.

That was discussed a few days ago. Seemingly the emoji palette is not enabled by default on LOS 18.1. It is a setting of AOSP keyboard.

[VaZso 1,998]

2 minutes ago, Slion said:

Again AltGr is Sym

It didn't work for me because I had Engliish layout selected but you are right, it works.
Sorry, I didn't see it every time I have tried.

However, losing two slant arrows for general purpose when not having any modifiers (like "FN" was on stock)...

[VaZso 1,998]

1 hour ago, Slion said:

I already have a first draft of that nf+tab as alt+tab feature.
It should have no impact on the rest of the driver functionality.
Only thing it does is let you use fn+tab exactly as alt+tab.

Do you mean you pass both slant arrows as "nf" to higher levels?

...or you did something related in driver level?

[Slion 1,201]

14 minutes ago, VaZso said:

Standard QWERTY (non-shifted naturally) but also

I'm not sure we understand each other.

Keymap: is the driver scancode mapping you have two option qwerty and qwertz you should set it to match your actual hardware.

Layout: is the android setting, french, us international, german, english and so on.

Look back at the questions I was asking and try to answer them again.

[Slion 1,201]

14 minutes ago, claude0001 said:

That works on LOS 16.

That was discussed a few days ago. Seemingly the emoji palette is not enabled by default on LOS 18.1. It is a setting of AOSP keyboard.

We ought to fix that, kinda useful I find.

[Slion 1,201]

8 minutes ago, VaZso said:

Do you mean you pass both slant arrows as "nf" to higher levels?

...or you did something related in driver level?

The later, just driver tweaks.

[Hook 3,020]

37 minutes ago, Slion said:

Does anyone knows why alt does not bring up the emoji keyboard on LOS like it did on stock?

Using English(US) layout, it does (except with software that takes over the keyboard like Softmaker Office).

[VaZso 1,998]

8 minutes ago, Slion said:

I'm not sure we understand each other.

Keymap: is the driver scancode mapping you have two option qwerty and qwertz you should set it to match your actual hardware.

Layout: is the android setting, french, us international, german, english and so on.

Look back at the questions I was asking and try to answer them again.

Right, keymap (hardware layout): QWERTZ

Software layout: English/US, but I would like to have an option to complement it to easily reach national characters

QWERTZ (as hardware layout) was much better as an international keyboard than QWERTY because the latter was shifted, so buttons apart from US alphabet were mixed up.

So, basically QWERTZ was the more like standard QWERTY than the one named as QWERTY which had mixed keys, that is why I chose QWERTZ.
Shifted QWERTY would not work well for international use as a lot of non alphanumeric buttons are in a very different place than a standard keyboard.

 

So, I would like to use QWERTY layout complemented by my national letters on a QWERTZ hardware keymap.

Imagine, if I write a sentence:
Bárcsak le tudnám írni ugyanezt a szöveget LineageOS alatt is kényelmesen...

I would need to add special characters where "í" does not even reachable on Hungarian keymap because "\" key is missing from hardware layout.
I had a solution which worked well under stock and it could also work here.

[raymo 177]

Hi there, I'm happy seeing people hard digging in Pro1 and LOS. Sadly I have no competence at this level, but seeing this make my journey 😄

Thanks not to give up.

I'm using LOS 18.1, and in keyboards aspect LOS17.1 was better, pressing Alt with Emoji is completely buggy, and a (very)few time ghost keys appears, I haven't see this since LOS16.1 in my first pro1 at the very beginning of LOS.

THANKS ! you are completly right ! CHEER UP !!!