LineageOS, Current status : 16.0 Test Builds

[Craig 1,435]

27 minutes ago, VaZso said:

Maybe that is the cause of only bottom speaker has audio in handsfree mode instead of top one.

 

I bet you're completely right.  The software is probably correct telling it which speaker to turn on, they're just wired wrong in hardware.  So when the speaker channels are swapped (hopefully in kernel?) then it that will solve itself.

[acoppens 45]

So I flashed test-build 3 and everything was fine.

Made sure to flash recovery to a and then flash the zip to b.

The only problem I'm running into is that I am having trouble sideloading nanodroid over adb :(.

At first I just tried to sideload from recovery, but then realized that if I was in recovery with b active it would probably try to install it to partition a which is not where I flashed the .zip.  -- rereading the instructions on the page about flashing gapps and they point this out as well.

Anyhow...then proceeded to set partition a to active before flashing, but still no dice.

In all instances the nanodroid wizard works perfectly...but when I reboot after installation f-droid and the aurora store are nowhere to be found - nor any of the other nanodroid changes.

Is this a known issue or am I doing something wrong?

Starting to get why the multi-partition thing can be annoying :P.

[tdm 2,322]

Sorry for the delay the last couple of days.  I have been playing around with the keyboard driver because I really hate the way that idealte did the keyboard logic.  It is, from my perspective, a gross hack that needs to go away.

 

Background: the bulk of the keys are handled by the aw9523b keyboard driver.  But the shift, ctrl, alt, fn (yellow arrows), and "fancy f" (aka. fxtec key) are wired up as gpio pins separately.  The easiest way for the oem to deal with this was to map the yellow fn keys in userspace.  It's a bit difficult to explain, so here's an example of how it works: when you press fn+p, userspace doesn't see "/", it sees fn+p.  The oem used the Android keyboard mapper to map fn+p to "/".  But this apparently only works when using the default keyboard layout, which is why switching away from the default to a typical layout like, say, "English (US)" in my case, breaks that mapping.

 

Fortunately, the keyboard gpio pins for shift/ctrl/alt/fn/fxtec are handled in the aw9523b driver file, so it's easy to hack on it.  I'm changing the logic to the following, more or less:

 

The fn keys are not reported directly.  The state of the fn keys are tracked as a variable.  The shift keys are reported and also tracked.  When one of the "normal" aw9523b keys are pressed, the fn state is checked:

* If no fn key is pressed, proceed as normal.  This means eg. shift+2 generates "@" as expected (currently it does not).

* If a fn key is pressed, consult a different keymap.  This keymap has a "force shift" flag.  If the force shift flag is set and no shift key is currently pressed, it will synthesize a shift press followed by the key and then a shift release.  So pressing fn+2 gets reported as shift, 2, unshift, which is interpreted in userspace correctly as "@".  As a bonus, I've also mapped fn+up/down to pageup/pagedown, fn+left/right to home/end.

 

So the end result is that the keyboard acts like a normal keyboard with no userspace keyboard mapping file.  You can select whatever layout you wish and it works normally.

 

Also, I must credit @netman for his work on the keyboard driver.  Without his updated driver, it would have taken me much longer to unravel the keyboard logic.

 

I'll be testing this as I do other things and it should show up in the next Lineage build.

 

[VaZso 1,992]

21 minutes ago, tdm said:

I'll be testing this as I do other things and it should show up in the next Lineage build.

I hope these improvements will be also available in stock Android.
@Waxberry, @Erik?

[Craig 1,435]

Hey Vaz, don't worry too much.  Chen and team are aware of these improvements and some will be included in next OTA update.   Be aware the software engineer that can implement such changes and get them pushed out OTA is currently stuck @ home along with the rest of China, and doesn't have access to dev tools, so patience may be required.    Odds are, lineage will be official before fxtec pushes out the next OTA 🙂

[tdm 2,322]

Been playing around with the new keyboard driver and it's working quite well. The only issue I've found that makes it behave differently from a regular keyboard is that the shift-key-unshift sequence breaks key repeat. I will look into deferring the unshift until the fn key is released to fix that.

 

[skrilax 5]

On 2/2/2020 at 9:29 PM, tdm said:

Well, a full answer to that question would be quite lengthy.  The brief overview is that there are different parts of the (cell) radio stack and certain parts are subject to vendor changes while others are not.  Generally speaking, Google and Qualcomm rarely agree on things outside basic things in the system and will implement them in different ways.  This leads to AOSP hardware support for Qualcomm devices (eg. used in Nexus/Pixel) having one set of code while the Qualcomm BSP code is different.  This is most apparent in things like advanced audio (compression, offloading) and the radio stack.  VoLTE has pieces in both of these.  Lineage tries to support both, but sometimes one implementation must be chosen or preferred over another.  Further, VoLTE is mainly used in India and when trying to use a GSM-only phone on a CMDA/LTE network.  I don't know any Lineage developers that use it, so it kind of gets neglected.  Combine these two and you have a broken and unsupported feature.

 

So how bad is IMS support on Lineage when it comes to Qualcomm nowadays? I remember (back from a few years back) that Qualcomm BSP wasn't as bad to get VoLTE etc. up unlike on Samsung.

[SteffenWi 139]

8 hours ago, tdm said:

So the end result is that the keyboard acts like a normal keyboard with no userspace keyboard mapping file.  You can select whatever layout you wish and it works normally.

Could you test and verify that selecting a different language setting in the Android settings / FxTec physical Keyboard thingi does change what characters appear on screen? Because, as described in my issue report, currently changing that setting doesn't do anything.

[netman 1,424]

12 hours ago, tdm said:

So the end result is that the keyboard acts like a normal keyboard with no userspace keyboard mapping file.  You can select whatever layout you wish and it works normally.

Won't this make handling different physical layouts like the qwertZ version of the phone and having custom mappings such as with finqwerty more difficult?

[tdm 2,322]

4 hours ago, skrilax said:

So how bad is IMS support on Lineage when it comes to Qualcomm nowadays? I remember (back from a few years back) that Qualcomm BSP wasn't as bad to get VoLTE etc. up unlike on Samsung.

I really don't know about IMS support.  All I've ever cared about on my phones was basic GSM service (voice, SMS, MMS, and data).  But the proprietary file list (which was stolen from the 1+5/5t) has an entire IMS section, so I would hope it works:

 

https://github.com/tdm/android_device_idealte_msm8998-common/blob/lineage-16.0/proprietary-files-qc.txt#L944

 

 

[tdm 2,322]

4 hours ago, SteffenWi said:

Could you test and verify that selecting a different language setting in the Android settings / FxTec physical Keyboard thingi does change what characters appear on screen? Because, as described in my issue report, currently changing that setting doesn't do anything.

I don't think the language setting affects the keyboard.  But if I select "German" for the keyboard layout, the characters on the keyboard change.  For example, the Y and Z keys are swapped -- pressing the physical "z" key generates "y", and pressing the physical "y" key generates "z".

 

[tdm 2,322]

1 hour ago, netman said:

Won't this make handling different physical layouts like the qwertZ version of the phone and having custom mappings such as with finqwerty more difficult?

 

I have not yet considered how to support qwertz, nor do I know how the OEM has implemented it yet.  Ideally the kernel would be able to detect the qwertz hardware and take care of the mappings internally.  But if that is not possible, I can implement a setting to change the physical keyboard layout and provide an option under the settings menu.

 

I've never used finqwerty.  But with my new keyboard driver, the keyboard will act exactly like a normal keyboard.  So I think finqwerty should behave exactly the same way on the physically attached keyboard as it does on a Bluetooth keyboard.  Is that difficult?

 

[_DW_ 628]

9 minutes ago, tdm said:

 

I have not yet considered how to support qwertz, nor do I know how the OEM has implemented it yet.  Ideally the kernel would be able to detect the qwertz hardware and take care of the mappings internally.  But if that is not possible, I can implement a setting to change the physical keyboard layout and provide an option under the settings menu.

 

I've never used finqwerty.  But with my new keyboard driver, the keyboard will act exactly like a normal keyboard.  So I think finqwerty should behave exactly the same way on the physically attached keyboard as it does on a Bluetooth keyboard.  Is that difficult?

 

Having an option isn't such a bad thing lets the user override if detected wrong at some point (they change something on newer models or something which breaks it)

[netman 1,424]

3 minutes ago, tdm said:

I've never used finqwerty.  But with my new keyboard driver, the keyboard will act exactly like a normal keyboard.  So I think finqwerty should behave exactly the same way on the physically attached keyboard as it does on a Bluetooth keyboard.  Is that difficult?

Finqwerty just provides a bunch of .kcm files to android via an API. Where I imagine that could become difficult is that currently there are mappings that use fn-key combinations that are not any fn-key combination on the physical print, if the driver absorbs the fn key events there would be no way to remap those combinations in userspace I guess.

A possible solution would be to provide an extra extra physical layout on the driver level as suggested for qwertz, where fn is a normal key and the user can figure out how to use it.

[VaZso 1,992]

35 minutes ago, tdm said:

I don't think the language setting affects the keyboard.  But if I select "German" for the keyboard layout, the characters on the keyboard change.  For example, the Y and Z keys are swapped -- pressing the physical "z" key generates "y", and pressing the physical "y" key generates "z".

That is correct, these characters are interchanged in QWERTZ layout.

24 minutes ago, tdm said:

I have not yet considered how to support qwertz, nor do I know how the OEM has implemented it yet.  Ideally the kernel would be able to detect the qwertz hardware and take care of the mappings internally.

I think they can not detect which layout is in use as Pro1s using QWERTY or QWERTZ layout only differs of where and which characters are printed on their keyboards - otherwise they are absolutely the same hardware.
...and as QWERTY is shifted and Pro1 internally generates correct scan codes for them and QWERTZ is not shifted, the latter has strange (shifted) scan codes...

So that is why layouts for QWERTZ Pro1 have "map key 41 Q" and similar lines in top of layout files to change mappings to meet prints on keyboard.

Edited February 5, 2020 by VaZso

[tdm 2,322]

4 minutes ago, netman said:

Finqwerty just provides a bunch of .kcm files to android via an API. Where I imagine that could become difficult is that currently there are mappings that use fn-key combinations that are not any fn-key combination on the physical print, if the driver absorbs the fn key events there would be no way to remap those combinations in userspace I guess.

A possible solution would be to provide an extra extra physical layout on the driver level as suggested for qwertz, where fn is a normal key and the user can figure out how to use it.

Yes I could certainly add an option to pass the fn key through.  Which would basically mean behaving like the stock keyboard.  Or pretty much anything else that is desired.

 

Oh, this reminds me.  You probably already know this but others here may not.  The two shift keys only generate a single key.  That is, the left and right shift key are indistinguishable at the hardware layer.  Same with ctrl.  But the fn keys are distinct -- you can tell the left from the right.  I don't know how this affects alternate keyboard layouts, but I though I'd mention it.

 

[elvissteinjr 355]

So if I got that right, the fn key state doesn't have to be hidden for this to work, correct? If no fn mapping is set in the active kcm file, there should be no drawback from having fn be down during the synthesized key press. In theory, at least.

I do have some doubts about switching between standard layouts to be practical at all even with this (physical layout just doesn't match up), but behaving closer to a PC QWERTY keyboard will probably be beneficial indeed.

QWERTZ does have yellow characters on other keys, including letter keys. Having proper fn key state will probably be required to map that correctly.

[tdm 2,322]

25 minutes ago, elvissteinjr said:

So if I got that right, the fn key state doesn't have to be hidden for this to work, correct? If no fn mapping is set in the active kcm file, there should be no drawback from having fn be down during the synthesized key press. In theory, at least.

I do have some doubts about switching between standard layouts to be practical at all even with this (physical layout just doesn't match up), but behaving closer to a PC QWERTY keyboard will probably be beneficial indeed.

QWERTZ does have yellow characters on other keys, including letter keys. Having proper fn key state will probably be required to map that correctly.

That is probably correct.  But if I passed the fn keys through, I would consider hiding them until another key is pressed.  If that other key does not have a yellow mark, pass the fn press and then the other key press.  In this way, the fn key is never seen as down unintentionally.

 

Edited February 5, 2020 by tdm

[VaZso 1,992]

33 minutes ago, tdm said:

That is probably correct.  But if I passed the fn keys through, I would consider hiding them until another key is pressed.  If that other key does not have a yellow mark, pass the fn press and then the other key press.  In this way, the fn key is never seen as down unintentionally.

I assume it has a strong drawback when using an international layout where user has access specific characters by pressing fn key and yellow keys are at unusual positions which is not compatible with national layouts.

Sticky fn is one thing but I often use fn+key combination regardless if it is sticky if it is at a convenient place.

So basically this idea is good but not practical here in general as I would like to use it a way where it passes fn to be able to work with other layouts which is mandatory for me.

[SteffenWi 139]

2 hours ago, tdm said:

I don't think the language setting affects the keyboard.  But if I select "German" for the keyboard layout, the characters on the keyboard change.  For example, the Y and Z keys are swapped -- pressing the physical "z" key generates "y", and pressing the physical "y" key generates "z".

 

Yeah that doesn't sound quite right. I think @EskeRahn pointed out that the hardware keys are shifted on the QWERTZ model, which means that on your keyboard, after switching to German layout, you should get a 'z' when you press the physical key 't'. Unless I misunderstood something.

Is it not possible to ask FxTec how they did it in their ROM and just copy their way of doing it?

Edited February 5, 2020 by SteffenWi

[EskeRahn 5,353]

19 minutes ago, SteffenWi said:

Yeah that doesn't sound quite right. I think @EskeRahn pointed out that the hardware keys are shifted on the QWERTZ model, which means that on your keyboard, after switching to German layout, you should get a 'z' when you press the physical key 't'. Unless I misunderstood something.

Is it not possible to ask FxTec how they did it in their ROM and just copy their way of doing it?

No. the hardware of qwertZ and qwertY are identical, it is merely the print on the keytops that are different.

(This is why entering the initial password on a qwertZ model preferably would be done using the touch/fake keyboard)

[SteffenWi 139]

@EskeRahn uh but you said here ->

that the keys are shifted? And if you use the QWERTZ layout with default settings and press 'z' you get a 't', instead of 'z' or 'y'.

Edited February 5, 2020 by SteffenWi

[EskeRahn 5,353]

11 minutes ago, SteffenWi said:

@EskeRahn uh but you said here ->

that the keys are shifted?

The hardware keytops/prints are different (primarily shifted). But the electronic is the same.
if I use a Pro1 with qwertZ print, without explicitly selecting "German" it acts as a qwertY (thus the keys not returning what is printed on them).

See e.g. this guide.

I wish they had added some magic flag, that said what print it got and handled it a deep level, but for simplicity they have not. So we ALL got a "Letter shifted QWERTY" device. Some of us with prints that does not match that, that needs a keymap to match the print. And this keymap can be either "German" or one of the options from FinQWERTY. If you select any of the others Latin-letters based layouts it will not make sense on a pro1 with qwertZ.

[SteffenWi 139]

1 hour ago, EskeRahn said:

The hardware keytops/prints are different (primarily shifted)

Sorry, I don't understand what you mean by 'primarily shifted'? And it doesn't address what I can observe currently. If I press 'W' 'Q' appears on the screen, if I press 'R' 'E' appears on the screen and so on. Numbers are fine. (as in if I press '1' '1' appears).

[VaZso 1,992]

20 minutes ago, SteffenWi said:

Sorry, I don't understand what you mean by 'primarily shifted'? And it doesn't address what I can observe currently. If I press 'W' 'Q' appears on the screen, if I press 'R' 'E' appears on the screen and so on. Numbers are fine. (as in if I press '1' '1' appears).

Basically, Pro1 comes with shifted QWERTY keyboard.
Its keyboard generates the same codes written on this shifted QWERTY keyboard as it should.

On QWERTZ keyboard of Pro1, hardware is exactly the same, only printing of keyboard is different.
So although QWERTZ has most of the keys moved back to its original location, the hardware's behaviour makes it shifted, generated keycodes are usually not match their original codes.
So on QWERTZ, these keys should be unshifted by software to be usable.

So he means the primary keyboard of Pro1 is QWERTY which is shifted (not the same as a real keyboard), so everything should be shifted back to work on unshifted QWERTZ.

Look at a photo of Pro1's QWERTY and QWERTZ layouts.

Edited February 5, 2020 by VaZso