How to customize the keyboard layout on LineageOS 18.1?

[VaZso 1,998]

20 hours ago, Sean McCreary said:

BTW, keycode 464 isn't handled properly by input_report_key(), so we would probably have to use a keycode < 255 and remap it in the Android .kl file to make that work.

Yes, it seems to be yet to done.

[EskeRahn 5,471]

8 hours ago, claude0001 said:

And, yes, of course, my bank allows me to make transactions from my "rooted" Thinkpad! Why should we look at smartphones any differently?

Well part of it is that could well be that in many countries the banks hold the responsibility for fraudulent activities on your account, unless they can prove that you have shown gross irresponsibilty, e.g. Sharing your pasword. And as security on phone banks apps are often down to simple four digits pins, and  phones are stolen more than laptops, it all adds up to higher risk for the banks, so at the least they want to reduce the risk of any troyan horse or the like accessing your bank app. And this is easier on rooted devices.

But of course they could offer an option of you taking all responsibilities, and then they could not care less on the security.

[EskeRahn 5,471]

6 hours ago, VaZso said:

I have uploaded temporarily the update file here.

@EskeRahn, @Slion and others who may have chance for it - could you please try it and tell me if you find anything which could be improved?

Edit:
Naturally, additional layouts (key arrangement) can also be applied more easily.

Have not tried it (I might find some time for it later) but I really think you should consider @Slion's idea of changing the initial qwertY/qwertZ switch to some radiiobuttons (or a drop down), collecting the settings in named sets. There could be one (say "custom") with all the options unfolding. But it will be terrible difficult for most user to understand the consequences of all the switches. It gets a bit like AICP: very customizable, but also very hard to set up for the normal user.

But if we are into switches, the alt or fn debate could be handled by letting that be yet another switch.

[claude0001 1,352]

4 hours ago, EskeRahn said:

And as security on phone banks apps are often down to simple four digits pins, and  phones are stolen more than laptops, it all adds up to higher risk for the banks

Well, authentication at an ATM is done using that same 4-digit pin. And banking cards get stolen all the time.  So I am not sure about that argument. 🤔

We are wandering off-topic here, but I think it is an interesting discussion, so let's go.

First, even looking at things in the most positive way, I fail to see how preventing root access from user space adds any security to the latter. After all, even with root access enabled, Apps do not gain that access right any more "easily" than any other permission. User interaction is required all the same.

But then, there are more fundamental aspects: Imho, hiding root access to users in an open-source operating system does not make sense by first principles: After all, anyone, including the user and the oh-so-trusted 3rd-party SoC vendors can implement any backdoor or other security breach they want prior to compiling the code. Once an App runs on Lineage, why should it care about "su" being present or not?    

That may seem too theoretical, so let's restrict the discussion to "official" Android distributions: Then, as @Rob. S. correctly points out, the most practically relevant security issue is still that device support relies on those hardware vendors, which abandon devices at a much higher rate than customers replace them. The Pro1 is a typical example (though by far not the worst): Stock Android 9 has dozens of published and unfixed vulnerabilities to privilege escalation. Also in that situation, hiding root access from the user does not really add any layer of security anymore.

Of course everyone, including Google, hardware vendors, and App publishers, know these things. So, I think all that noise around rooting is there mainly to cloak the fact that Android security, as implemented today, is broken by Android's very publishing model.

Edited August 30, 2021 by claude0001

[EskeRahn 5,471]

2 hours ago, claude0001 said:

We are wandering off-topic here, but I think it is an interesting discussion, so let's go.

Look at it another way. Why should a bank care if they did not see a reduction in their risk of loosing money somehow?

[VaZso 1,998]

6 hours ago, EskeRahn said:

Have not tried it (I might find some time for it later) but I really think you should consider @Slion's idea of changing the initial qwertY/qwertZ switch to some radiiobuttons (or a drop down), collecting the settings in named sets. There could be one (say "custom") with all the options unfolding. But it will be terrible difficult for most user to understand the consequences of all the switches. It gets a bit like AICP: very customizable, but also very hard to set up for the normal user.

You are right, it could be done in a bit more beautiful look or even provide an additional "very special area" another button.
However, I am not  familiar with Android programming so I am not prepared to do something like this.
I was happy to make it work the way similarly that of existing options.

However, for most users, there is no need of entering advanced settings, so I hope it should not be a really big problem as it also works the same way as before without doing any modifications on these options.

Also, others may also use it as a base and do further modifications - I am sure that @Slion (for example, sorry for mentioning) could do this part  light years better as I saw he did a lot of related work.

Anyway, I was starting to put it up to Gerrit very late in the night and I failed to put a modification well, then created a lot of mess not really knowing what is going on and an additional tireness of not sleeping even at 6am and on..., so I may need to correct them somehow.... :S

Currently it is waiting for review anyway... or maybe something like this.

[claude0001 1,352]

46 minutes ago, EskeRahn said:

Look at it another way. Why should a bank care if they did not see a reduction in their risk of loosing money somehow?

Sounds a bit like "Trust the authorities, they will know what is good for us." 👮‍♀️

I am not saying they have no reasons for doing what they do. I am saying that those reasons have nothing to do with technology and are thus not valid.

I believe they check against rooting as that breaks the App for only few technically-skilled customers, while giving all others the warm feeling that they care about security.

Technically, checking the Android patch level (and refusing to run on outdated systems) would make much more sense. However they will never do that as it would affect way to many clueless users who happily run their 3-years-outdated phones, because, you know, it still "works" and -- after-all -- it's not rooted, so what could possibly go wrong?! 🙃

Edited August 30, 2021 by claude0001

[Sean McCreary 328]

On 8/28/2021 at 11:26 PM, Sean McCreary said:

There does seem to be a bug in the settings app that is preventing this from working 😞 I will try to figure out why.

Fixed. The CR is under review here: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315298

Oh, and there is an associated SELinux policy change that is also needed, but the implementation is still under discussion

Edited August 30, 2021 by Sean McCreary
Add note about SELinux policy issue

[VaZso 1,998]

1 hour ago, Sean McCreary said:

Fixed. The CR is under review here: https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315298

Fine, thanks.

My head is not the best as I have slept too few hours (and tomorrow I am going to travel and get up early), but do you know more about the reason why import_report_key() function drops KEY_FN?

I have found that issue but forgot to look at it and also it was mentioned here - maybe you or somebody mentioned it a few days ago.

[Slion 1,201]

17 minutes ago, VaZso said:

do you know more about the reason why import_report_key() function drops KEY_FN?

Looking at your changes you did not setup in the KL file. See:

 

Edited August 30, 2021 by Slion

[VaZso 1,998]

17 minutes ago, Slion said:

Looking at your changes you did not setup in the KL file. See:

 

Thanks.
I have remembered this comment but not where I have read it.

Also, I don't know the exact way of Android to Linux keycode conversation...

So, if I understood correctly, the Linux keycode of KEY_FN (434) is passed to the Android keyboard handler which does not have anything associated, so it simply drops it.

Using the way described in your code review, if I would define similarly to your "key 154   APP_SWITCH" define, it would associate "key 434" with... something.

Should that "something" need to be a deeper defined thing or am I allowed to simply define "key 434  434" for it to appear in Android?

Stock OS may had a similar association (I could see 434 in button event viewer), however, it may happen it is not recommended to do it this way but maybe to define it elsewhere...

[Slion 1,201]

33 minutes ago, VaZso said:

Thanks.
I have remembered this comment but not where I have read it.

Also, I don't know the exact way of Android to Linux keycode conversation...

So, if I understood correctly, the Linux keycode of KEY_FN (434) is passed to the Android keyboard handler which does not have anything associated, so it simply drops it.

Using the way described in your code review, if I would define similarly to your "key 154   APP_SWITCH" define, it would associate "key 434" with... something.

Should that "something" need to be a deeper defined thing or am I allowed to simply define "key 434  434" for it to appear in Android?

Stock OS may had a similar association (I could see 434 in button event viewer), however, it may happen it is not recommended to do it this way but maybe to define it elsewhere...

464 is by default associated with FUNCTION on Android:

https://android.googlesource.com/device/google/atv/+/master/Generic.kl

However for some reason @Sean McCreary wants us to use scan codes below 255.

In your changes you took over some of Sean's defining left function as 195 and 196.

That mean you should have something like that in your KL file:

key 195 FUNCTION
key 196 ALT_RIGHT

Providing that you want the left function key to be passthrough as FUNCTION and the right function key to be passthrough as ALTGR which I reckon is the way we should go. I'm going to post about that again soon.

Edited August 30, 2021 by Slion

[VaZso 1,998]

16 minutes ago, Slion said:

464 is by default associated with FUNCTION on Android:

That is perfect, thank you - I think that is why it can be used in .kcm files as FUNCTION 🙂
...but that also mean this should be used in .kl, so thanks again.

16 minutes ago, Slion said:

In your changes you took over some of Sean's defining left function as 195 and 196.

Yes, I have used them for slant arrows.

16 minutes ago, Slion said:

That mean you should have something like that in your KL file:

key 195 FUNCTION
key 196 ALT_RIGHT

I think no - key 195 and 196 may remain intact (unused) but keyboard driver may report 464, so I should do the map of:
key 464  FUNCTION

...at least this is what I thought it would work.

In the driver what I am worked on, there is a variable which defines the scancode of each function keys present (so left arrow, right arrow and f(x) key). This variable can be set using /sys directory, so that way these keys can be exposed directly as "FUNCTION" which is what I wanted to do (among AltGr and the others).

Also keyboard layout map will provide this code if the appropriate KF_FN modifier was set.

I went to a direction where these keys may be defined independently, so even all of them could be FN that way and even none of them, it is the choice of end user and does not need hardcoding it (nor AltGr).

Edited August 30, 2021 by VaZso

[EskeRahn 5,471]

13 hours ago, Slion said:

However for some reason @Sean McCreary wants us to use scan codes below 255.

Most likely a scancode for historical reasons is a byte, somewhere in the 'pipeline', so the map to 464 must happen later.

[Slion 1,201]

1 minute ago, EskeRahn said:

Most likely a scancode for historical reasons is a byte, somewhere in the 'pipeline', so the map to 464 must happen later.

I doubt that, 464 is the actual FUNCTION default in Generic.kl so definitely not a Linux or Android limitation.

I wonder if @Sean McCreary may have fixed it last night.

[Sean McCreary 328]

1 hour ago, Slion said:

I doubt that, 464 is the actual FUNCTION default in Generic.kl so definitely not a Linux or Android limitation.

I wonder if @Sean McCreary may have fixed it last night.

To be absolutely correct, @tdm fixed it. I just did the typing 😉

[Sean McCreary 328]

After a bit of thought, it seems like we can enable most of the remapping scenarios people have requested if we create a method for remapping the six modifier keys: shift, ctrl, fn_l, home, alt, and fn_r. I am proposing a new remapping interface that will accept a list of keycodes for these six keys, where 0x00 will designate a key that should operate the way Fn does currently (i.e. no keycodes are sent to Android, and it 'shifts' the internal kernel keymap instead).

This will allow maximal remapping of the keyboard, but also enable every possible key combination. I am specifically proposing that each Fn key be treated independently, allowing fn_r to be remapped to 'alt' while simultaneously permitting fn_l to continue functioning as it does now.

Note that this would allow the user to disable the internal kernel keymap 'shifting' entirely by assigning keycodes to all six modifier keys. While I think this is a valuable feature, there's not really a good argument to force anyone to use it.

[Slion 1,201]

51 minutes ago, Sean McCreary said:

After a bit of thought, it seems like we can enable most of the remapping scenarios people have requested if we create a method for remapping the six modifier keys: shift, ctrl, fn_l, home, alt, and fn_r. I am proposing a new remapping interface that will accept a list of keycodes for these six keys, where 0x00 will designate a key that should operate the way Fn does currently (i.e. no keycodes are sent to Android, and it 'shifts' the internal kernel keymap instead).

This will allow maximal remapping of the keyboard, but also enable every possible key combination. I am specifically proposing that each Fn key be treated independently, allowing fn_r to be remapped to 'alt' while simultaneously permitting fn_l to continue functioning as it does now.

Note that this would allow the user to disable the internal kernel keymap 'shifting' entirely by assigning keycodes to all six modifier keys. While I think this is a valuable feature, there's not really a good argument to force anyone to use it.

Maximal flexibility sounds good to me but sensible defaults is also important as most people will just use that. Also keep in mind that you can already remap your modifiers from KCM. However being able to remap them from our keyboard advanced settings sounds a lot more practical to use assuming this is what you have in mind.

[Slion 1,201]

1 hour ago, Sean McCreary said:

the six modifier keys: shift, ctrl, fn_l, home, alt, and fn_r

It's actually seven, you forgot Sym.

[Sean McCreary 328]

3 minutes ago, Slion said:

It's actually seven, you forgot Sym.

To be clear, I am talking about the six keys attached to dedicated GPIO lines. the SYM key is #24 in the keyboard matrix, currently mapped to KEY_RIGHTALT but also remappable using the existing custom keymap feature.

[Sean McCreary 328]

13 minutes ago, Slion said:

Maximal flexibility sounds good to me but sensible defaults is also important as most people will just use that. Also keep in mind that you can already remap your modifiers from KCM. However being able to remap them from our keyboard advanced settings sounds a lot more practical to use assuming this is what you have in mind.

The current custom keymap feature does not support remapping shift, ctrl, alt, home, or either fn_l or fn_r.

[Slion 1,201]

7 minutes ago, Sean McCreary said:

The current custom keymap feature does not support remapping shift, ctrl, alt, home, or either fn_l or fn_r.

So you want to extend our keymap to support them too? Sounds good to me.

Edited September 1, 2021 by Slion

[Hook 3,043]

Just curious.  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, maybe to right_fn and shift-right_fn? (because that is a more normal qwerty keyboard position for those symbols).

[Sean McCreary 328]

17 minutes ago, Hook said:

Just curious.  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, maybe to right_fn and shift-right_fn? (because that is a more normal qwerty keyboard position for those symbols).

That is a case which could *almost* be supported with the additional key remapping feature I am proposing. Currently the '/' and '?' mapping via Fn+P and Fn+L is remappable, as those keys are #28 and #31 in the keyboard matrix. The new idea is to allow remapping additional keys, which would allow you to use a custom keymap to remap  fn_r to a single keycode. Two make the keycode it generates vary by context in the kernel, you would have to use 'shift' as the internal kernel keymap shift key (how KEY_FN is currently used in the driver), which would have  side-effects for the rest of the mapping. You could make it work, but it would mean remapping almost every other key to compensate.

Now, in this particular case Android will map Shift+/ to '?' so you really don't need to worry about the details of the explanation above. If you choose to map fn_r to '?' it ought to work like you want 😉

Edit: I included two different answers above, and they are intended for different audiences. I think the latter one answers the specific question asked, but the former one addresses the general case.

Edited September 1, 2021 by Sean McCreary
Context for two different answers

[VaZso 1,998]

2 hours ago, Sean McCreary said:

After a bit of thought, it seems like we can enable most of the remapping scenarios people have requested if we create a method for remapping the six modifier keys: shift, ctrl, fn_l, home, alt, and fn_r. I am proposing a new remapping interface that will accept a list of keycodes for these six keys, where 0x00 will designate a key that should operate the way Fn does currently (i.e. no keycodes are sent to Android, and it 'shifts' the internal kernel keymap instead).

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.