tdm

Forward looking.

Unfortunately I haven't been able to build abl yet. I know it's possible, as an fxtec developer said he was able to build it. He was using a different like Linux distro than me, which may be the issue. One of these days after lineage and the factory restore tool are both humming along without issues I'll try again.

I'm working on the changes to allow selecting qwertz in the kernel hardware key map. I should have something to test tomorrow.

Hmm, okay. If the hardware codes are the same then I should be able to work that out. My plan is to allow the user to select the keyboard variant, qwerty or qwertz. The selection should be saved (eg. in /persist) so it only needs to be done once. User space will write the variant to a kernel sysfs node, which will switch the hardware keymap. The end result is that you should be able to operate the keyboard exactly like a USB keyboard, selecting the built-in German layout.

Excellent, thank you. So now I need to know what hardware key codes qwertz/German keyboard is supposed to emit. For example, the key to the right of zero is "ß". This, as far as I can tell, has no key defined in the kernel's input-event-codes.h. So what code does it use? Perhaps it would be useful to connect a Bluetooth qwertz keyboard to discover all the key codes. If anyone wishes to try this, you should be able to run "getevent" in an adb shell to see the keycodes. Note you cannot run "adb shell getevent", you must run "adb shell" and then at the prompt run "getevent". Yo

Is this an accurate picture of the qwertz variant?

Okay all, I finally found some time to look at this some more. As it turns out, the xbl partitions are not actually being written by the current package due to a bug in the programming instructions. Or, well, a mismatch between what the programming instructions say and what my program expects it to say. Anyway, I'll fix this and have a new package up shortly. This should be able to fix the currently bricked devices (I know there are at least two out there at the moment).

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.

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.

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 keyboar

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

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

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.

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: wh

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

Yeah it seems broken here also. I must have broken it yesterday, possibly with my audio prop change. I'll get that fixed and the fingerprint data fixed for Monday.

Yes the signing keys change for official but there is a simple way around wiping for that. I'll check BT audio again, but it's been working for me since I built the vendor image myself.

Alright after all the issues, I have flashed the "official" test3 zip on my device and wiped data. It works perfectly fine. @SteffenWi have you figured out the virtual keyboard issue? It works fine for me, from the very start when asked for a PIN on the lock screen. I just need to press the keyboard icon on the right side of the navbar and select "Show virtual keyboard". (I will try to make this the default in the future).

I suspect something with the built vendor image is different than the stock vendor image. @Gigadoc2 mentioned a few posts back that he had to wipe after the switch, and I guess we now have two people that have confirmed it. I'm sorry for that, wiping data is usually not necessary -- even in the test stage. It should not be necessary again.

Please try wiping data.

@skrilax I've put a userdebug zip in the server. It's not linked, just replace user with userdebug to get it.

@bmccrary Can you adb in to recovery? You can edit build.prop and set adb on at boot to see the error in the log.

No, that is strange. This usually happens when data fails to mount/decrypt. Had you previously been running test2? Full disclosure: I didn't test this exact zip, I flashed one that I built on another machine. But it should be the same exact code. I can try this one later tonight or tomorrow if others also have problems.

Actually boot_a works and I use it to be explicit. But test2 should be test3.

No way to tell. The fingerprint files are just tossed into the bsp as binaries. So only BetterLife (the fingerprint vendor) knows for sure. Edit: yeah for FDE, data is decrypted long before the FP service starts.