tdm

I found some missing libs yesterday. I almost pushed a new build but decided to wait until I investigated a2dp a bit more. Should have a new build in a few hours either way.

There are only 7 actual keys in row 0. https://github.com/tdm/android_kernel_idealte_msm8998/blob/lineage-16.0/drivers/input/keyboard/qx1000.c#L252

I believe the layout of the symbol keyboard is overridable by the device at build time, but not run time. The behavior is most likely not overridable at all.

This is for stock... https://github.com/tdm/android_kernel_idealte_msm8998/blob/oem-history/drivers/input/keyboard/aw9523b.c#L1901 https://github.com/tdm/android_kernel_idealte_msm8998/blob/oem-history/drivers/input/keyboard/aw9523b.c#L865 I changed those in Lineage.

Unlikely, but we shall see. The change that enables the accent chooser is the same one that enables sticky shift: setting the keyboard type to ALPHA in the kcm file (instead of FULL). I'm not sure if that can be overridden. Perhaps others could investigate.

I would not hold my breath on this. Just off the top of my head I can name several show stoppers that any "decent" "enterprise" (*) IT policy would require: - Secure Boot is disabled. - Security patch level is out of date. - WiFi and BT MAC addresses are bogus. (*) definitions of decent and enterprise may vary, and frequently do.

It's a known bug in the keyboard driver. Certain keys are "dead" at reboot until you press any other key. I have not heard whether there are plans for a fix soon. But it's already fixed in Lineage.

Sorry that the phone didn't work out for you. Certainly there are different ideas about what hardware looks and functions best. But I must admit the software is currently a weak spot. I'm going to respond to the software issues. Please keep in mind that I am not employed by FxTec, I'm just a developer who was given a device to get LineageOS running on it. Further, I'm not really a "keyboard phone" type, this is my first keyboard phone (but my wife used to love her Relay 4G, which is why I was the Cyanogen dev for that device for a while). I have gotten to know Chen and a few other

It's mostly just a reminder for me to look at the code. The current lights code hasn't really been tested or anything, it was just brought along with the initial stuff from 1+5/5t.

Please file an issue on the tracker and I'll look at it probably Monday. I'm already in the lights code with the keyboard backlight.

This is one of the "other issues" that I mentioned in my earlier post. The vendor data and framework data get out of sync under certain conditions, for example when you wipe data (aka. factory reset). This is a problem because the vendor data only seems able to hold 5 fingerprints and doesn't seem to ever delete its data. So once you have registered 5 fingerprints total, any further fingerprints registered will not be saved in the vendor data until the vendor data in /persist is deleted (this is why it works until you reboot). Deleting the vendor data in /persist requires root acce

There are two places in the code that handle fingerprint data. The vendor code is responsible for storing the actual fingerprint data corresponding to your finger and assigning it an identifier (ID). This particular FP vendor stores its data under /persist which has caused other issues. The vendor code tells the Android framework its list of ID values on request. Android stores the ID values and some other bits of information in another place (under /data). It is possible (I would say likely) that the issue is in the vendor code. It probably isn't actually deleting your finger

Been hacking on the lights HAL this morning (shhh, don't tell my wife). I think I've got the logic figured out so that the keyboard backlight always keeps the proper state (which is, on only when both the screen is on and the slider is out).

Thanks. So the issue isn't calling specifically but something in the audio stack that calling uses.

I cannot confirm nor deny any audio changes, as I'm not at a PC. Look at the proprietary files lists to see what is copied from stock. The rest is built. Edit: also look at the vendor audio props.

@JooJooBee666 yes I'm aware that audio still has issues. I plan to make that top priority for next week. But feel free to poke at it before then. :) The issue with stock vendor is the fstab -- stock uses FDE and lineage uses FBE. You need to do some shenanigans to overlay the lineage fstab to let it boot with stock vendor.

FYI .. I'm heading out of town shortly and won't be back until Monday. No new builds until then. I'll leave you with a Lineage splash that I made just for fun: Lineage Splash Flash this to the "splash" partition with fastboot. Here's the original in case you want to go back: Stock Splash

Hmm, that is odd. When is the last time you checked GSM calling? The vendor update did not change much: $ git show --name-only HEAD | grep "^pro1" | egrep -v "(jar|apk)$" | egrep -v "(chromatix|camera)" pro1/proprietary/vendor/etc/sensors/sensor_def_qcomdev.conf pro1/proprietary/vendor/firmware/ipa_fws.b01 pro1/proprietary/vendor/firmware/ipa_fws.elf pro1/proprietary/vendor/firmware/ipa_fws.mdt Can someone else verify that GSM calling works? As for the clock, I haven't changed anything there. Qualcomm devices don't keep time between reboots, so ti

I've done a bit of testing with SIP this morning because I haven't gotten voice working with my cell provider. Both inbound and outbound SIP calls seem to work fine. So any calling issues must be with the actual cell radio.

This issue should still be in the current kernel. Please file an issue on github so I will remember to fix it.

Thanks, I may take you up on this at some point.

I believe it is turned off when the device is sleeping (not necessarily just when the screen is off or when the slider is closed). At least that is what the code says. My plan was to detect when the screen is off and send KEY_WAKEUP instead of the pressed key (eg. eat the keypress).

I'm using GSM (an AT&T MVNO) so I don't use VoLTE. Is there any way to test VoLTE in the US without signing up for VZW service?

Hey so quick question ... Sean and I are chatting about the virtual keyboard behavior. It seems that telling Android the keyboard is not internal causes the device to wake on any key but also is responsible for the virtual keyboard popping up when it shouldn't. So I think I'm going to revert that change and figure out how to wake the device with the internal keyboard. There are certain keys that do this -- among them, BACK and WAKEUP. I can send WAKEUP for any or all keys, so which do you guys prefer? Only a certain key (like ESC) waking the device or any key?

I've started going through the issues on the github issue tracker. There are relatively few things left to fix to get a good stable build, shown below in rough order of severity (IMHO anyway): * General stability. @Craig reported that test4 was unstable. Please try test6 and report back. * Phone call audio issues. * a2dp does not work. * Virtual keyboard showing and hiding at appropriate times. * FM Radio does not work. * WiFi signal strength does not work. * selinux is permissive. Other less severe issues that probably shouldn't be considered