How to customize the keyboard layout on LineageOS 18.1?

[VaZso 1,998]

1 hour ago, VaZso said:

...just I need to go through this build process on my own machine (find out what's wrong) and I can even test it if I can solve it till the end of this weekend.

I think it has something to do with my local filesystem which I think it may not support "d_type == DT_DIR" check which the utility would use...

It seems to get a bit complicated... :S

I will probably have to make a filesystem in a file of maybe around 200GB, mounting it as a loop and starting it over again... my SSD will be "very happy" after I go through it...

What is the final size of LineageOS after a finished compile?

[Slion 1,201]

5 hours ago, VaZso said:

is still not a final solution as somehow it does not load it upon boot (I have to run it manually) and a rootless solution would be much better.

That's certainly because of that bug where the custom keymap is not loaded as it should. That ought to be fix.

 

5 hours ago, VaZso said:

Anyway, I have looked into the code and adding some options to advanced keyboard settings or adding physical layouts are seem to be really simple and straightforward.

Agreed, just needs to be done and tested carefully. That takes time too.

5 hours ago, VaZso said:

just I need to go through this build process on my own machine (find out what's wrong) and I can even test it if I can solve it till the end of this weekend.

Looks like your build is broken somehow. Mine worked on WSL. Though downloading the blobs had to be done over tcpip with adb as it can't be done over usb. Maybe try using another Linux environment or identify your problem.

[Slion 1,201]

@VaZso Maybe you are missing some packages (apt-get) and that broke your build in a not obvious way.

[VaZso 1,998]

37 minutes ago, Slion said:

That's certainly because of that bug where the custom keymap is not loaded as it should. That ought to be fix.

Yes, it is. Maybe something does not run or not in the right time...

37 minutes ago, Slion said:

Agreed, just needs to be done and tested carefully. That takes time too.

Right. Also it checks for the existence of custom keymap file, and if so, it disables keyboard-related options (so not only if it was enabled, but also if it exists).

I think it was in use during testing and didn't really take much attention otherwise.

33 minutes ago, Slion said:

@VaZso Maybe you are missing some packages (apt-get) and that broke your build in a not obvious way.

No, everything was fine except the filesystem.

It checks for a directory using a method which is not supported under certain filesystems (but only a few).
Now it compiles since about 3 hours I think, so it will go through if it does not run out of space.

Edited August 27, 2021 by VaZso

[claude0001 1,352]

11 hours ago, Slion said:

Did you guy ever get stuck in a mode where capslock is inverted?

Do not worry, has happened to me once on LOS 16, too. I did not reasearch the issue, though. Just rebooted. 🤗

[claude0001 1,352]

1 hour ago, VaZso said:

a method which is not supported under certain filesystems (but only a few)

Why am I not surprised you are using a different filesystem than everyone else? 😉

Good luck with the new build!

[VaZso 1,998]

15 minutes ago, claude0001 said:

Do not worry, has happened to me once on LOS 16, too. I did not reasearch the issue, though. Just rebooted. 🤗

I have experienced it again on LineageOS today.

CapsLock was off and it has started writing capitals.
Changing CapsLock state had no offect but pressing and releasing shift had - it stopped doing it after I have pressed it once.

I don't know if it missed a release state or what happened anyway but here is official LineageOs 18.1 running on previous build (not the actual latest).

[claude0001 1,352]

5 minutes ago, VaZso said:

Changing CapsLock state had no offect but pressing and releasing shift had - it stopped doing it after I have pressed it once.

That's different.

When you write all caps irrespective of the CapsLock state, you are in "Super-Sticky-Shift" mode. One enters that by hitting Shift twice (without pressing any other key). Disable by one more Shift press. That's a feature, not a bug, I guess. 🙂

The phenomenon @Slion mentioned is an inversion of CapsLock. I.e. with LED on you type minor letters, with LED off capitals.

[Slion 1,201]

10 minutes ago, claude0001 said:

When you write all caps irrespective of the CapsLock state, you are in "Super-Sticky-Shift" mode. One enters that by hitting Shift twice (without pressing any other key). Disable by one more Shift press. That's a feature, not a bug, I guess. 🙂

Can't enter that mode. Is that a driver feature or virtual keyboard feature?

[Slion 1,201]

22 minutes ago, VaZso said:

Changing CapsLock state had no offect but pressing and releasing shift had - it stopped doing it after I have pressed it once.

In my case that did not help. Only capslock toggle would.

[claude0001 1,352]

13 minutes ago, Slion said:

Can't enter that mode. Is that a driver feature or virtual keyboard feature?

No idea. I use the normal AOSP keyboard shipping with LOS 16. I suspected it was a feature of the latter, but at first sight I can't find any setting related to that.

When I hit-and-release "Shift" once (without any other button), I enter "normal-sticky" shift, i.e. the next letter is capitalized, the following ones are lower case again. This is a quite common accessibility feature to enable use of a keyboard with a single finger (for e.g. disabled people).

Hitting "Shift" twice makes capitalization "super-sticky" for me, meaning all letters are entered as capitals until "Shift" is pressed once more. This overrides the CapsLock state.

Edited August 27, 2021 by claude0001

[Slion 1,201]

@claude0001 Looks like sticky shift was disabled on LOS18.1.

Just as well as I'm not a big fan of that. If I recall well it's a build time configuration somewhere (root KCM?) where you can define the type of keyboard yours is, thumb or full. Thumb keyboards will give you those sticky behaviours and full won't.

[claude0001 1,352]

21 minutes ago, Slion said:

Can't enter that mode. Is that a driver feature or virtual keyboard feature?

I should add that this does not work in all apps. E.g. sticky shift works in Firefox, K9-Mail and 1+Term, but e.g. not in ConnectBot or CollaboraOffice.

So probably Apps can opt-in and out of that feature.

[Slion 1,201]

Created a separate thread to discuss that keyboard driver feature I'm trying to contribute:

 

[Hook 3,043]

3 hours ago, Slion said:

@claude0001 Looks like sticky shift was disabled on LOS18.1.

Just as well as I'm not a big fan of that. If I recall well it's a build time configuration somewhere (root KCM?) where you can define the type of keyboard yours is, thumb or full. Thumb keyboards will give you those sticky behaviours and full won't.

Sticky shift (and super-sticky-shift) work fine here on 18.1, using AOSP as soft keyboard as @claude0001 indicated.

[VaZso 1,998]

5 minutes ago, Hook said:

Sticky shift (and super-sticky-shift) work fine here on 18.1, using AOSP as soft keyboard as @claude0001 indicated.

Right, this also works here (that was I ran into).

[EskeRahn 5,471]

12 hours ago, claude0001 said:

When you write all caps irrespective of the CapsLock state, you are in "Super-Sticky-Shift" mode. One enters that by hitting Shift twice (without pressing any other key). Disable by one more Shift press. That's a feature, not a bug, I guess. 🙂

What keyboard software are you using? Where did you try this? This mode can not be triggered as described with the default AOSP keyboard, in settings search field.
Ignore above, tested fx service... thanks @Jacob_S

[claude0001 1,352]

3 minutes ago, EskeRahn said:

This mode can not be triggered as described with the default AOSP keyboard

Works for me with AOSP keyboard on LOS 16.0. Others report it also works on LOS 18.1.

So maybe the feature can be switched on/off somewhere. Do not know where, though ...

Edited August 27, 2021 by claude0001

[EskeRahn 5,471]

5 minutes ago, claude0001 said:

So maybe the feature can be switched on/off somewhere. Do not know where, though ...

Indeed settings are spread all over so can be hard to find, unless you can guess a keyword and find it by search....
I'm currently looking for the rather odd 'feature' of vibration feed-back on hardware-keyboard touch. And no the setting for haptic feedback on touch is not coupled with this.

[Jacob_S 128]

1 hour ago, EskeRahn said:

Indeed settings are spread all over so can be hard to find, unless you can guess a keyword and find it by search....
I'm currently looking for the rather odd 'feature' of vibration feed-back on hardware-keyboard touch. And no the setting for haptic feedback on touch is not coupled with this.

You don't have F(x) Service installed by chance? ;)

[Slion 1,201]

1 hour ago, Jacob_S said:

You don't have F(x) Service installed by chance? 😉

@EskeRahn Ho yeah, it could be enabled by default in Fx Service 🤣 sorry about that…

[Sean McCreary 328]

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.

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

[VaZso 1,998]

37 minutes ago, Sean McCreary said:

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

Honesty I don't know what is this layout good for a QWERTZ unit.
I gave up on finding out if it has any real value as it does not really seem to be usable at all for me (not only that one button)...

Currently I am working on a modification of keyboard driver and settings UI which will allow us to set a lot of features and setting up also slant arrow and F(x) key as any modifiers (basically anything) and even unexposed mode, so I would like it to fit for all use cases...

Basically kernel interface is actually working, menu items are there with appropriate options, I still have to look near communication between ui setting and kernel interface and some behaviour at reloading settings to take appropriate effect.

Anyway, finally I gave a 300GB partition to it (basically it is in a file as it had a problem on my filesystem) and compile took around 3.5 hours for me.

A recompile usually takes around 8 minutes.

One thing I don't know yet is the update process...
I have sideloaded my own build a few times (after some modifications) and I had to do a factory reset every time after it.
I don't know if the amount of time I wait is too few or it can't reach data partition having a different key (I hope not that is the problem)...

I have sideloaded the build, then Magisk, then MindTheGapps but somehow it seems to not boot until I do a factory reset again, then it starts normally...

So, currently I am working on it and it will work sooner or later. 🙂

I have to eat something but even it would be good to go sleep... 🙂

Edited August 28, 2021 by VaZso

[Sean McCreary 328]

On 8/26/2021 at 3:11 PM, Slion said:

Did you guy ever get stuck in a mode where capslock is inverted? Like when capslock is on you get lowercase and when it is off you get uppercase. I'm testing my modified driver but I'm pretty sure I did not do break that as I did not touch handling of shifts or caps.

This is normally because META+ALT acts as CAPSLOCK in Android, but does not turn on the LED embedded in the CAPSLOCK key. If your shift state is reversed, try pressing the 'F logo' and 'Alt' key next to it together.

[Sean McCreary 328]

I tried to read through the lengthy discussion from the past week, and I hope I got the gist. But please correct me if I mischaracterize anything below.

The problem with the FinQwerty solution that worked on the stock OS is that it required a new map for each physical layout, while the set of language-specific key character maps supplied with Android were basically useless. @tdm managed to fix this by creating a new keymap layer in the kernel keyboard driver, allowing the key character maps supplied with Android to work with the built-in keyboard of the Pro1.

Now, things got a little more complicated when he implemented the QWERTZ kernel keymap. Because the Pro1 keyboard doesn't have enough modifier keys, he tried to make the Fn keys generate different modifiers based on context. This is why the 'KEY_7 | KF_ALTGR' syntax in the qwertz_fn_keys[] array was needed. The flag added to the keycode is interpreted by the driver as a 'chord' of key presses, emulated by sending multiple key events to Android. This is why an event monitor will see 'extra' keycodes when those keys are pressed.

Now, it is certainly possible that this clever feature causes some problems with custom key mappings. @VaZso, could you post the custom key map that didn't work properly so we can do some debugging?