tdm

@auvo.salmi the idea for the Lineage keyboard driver is to emulate a full PC keyboard. @Gigadoc2 had a long and detailed reply on the github issue page, which is very informative and I encourage others to read here. The idea is that you select your physical keyboard as QWERTY or QWERTZ and then let the standard Android keyboard layout stuff do its thing. I do not have a QWERTZ device. And even if I did, I am a sheltered mono-lingual American so I wouldn't know how it's supposed to behave. The current QWERTZ layout was done with a picture of a QWERTZ pro1 device and a picture of

Certainly it would be nice if someone official created an issue tracker. But until that happens, I think github issue tracker is much nicer than a spreadsheet. If someone could import the spreadsheet into the issue tracker that would be really nice. Heck, I might even make a new stock build with some of the issues fixed... 😄

Similar to pretty much any other Android phone, you do a build by pulling binaries off the device. I don't know if FxTec has provided any "official" kernel sources but this repo has the full OEM history, which is a step above your typical "here's a tarball" that most every other OEM does: https://github.com/tdm/android_kernel_idealte_msm8998/commits/oem-history

Modem crashes are always fatal, eg. reboot AFAIK. And the modem software is completely closed source. The OEM may have the source, I don't know. If they do, I might be able to build a kernel that crashes to ramdump mode. This would allow you to pull a copy of the device state at the time of the crash and send it to the OEM for analysis.

Since both devices are Linux, I need to clarify... you need to be root on the host or on the phone? If it's on the host, which I assume since there isn't any official way to become root on stock, it is likely because your udev rules are not marking the specific vid:pid used by the pro1 as owned by the correct group. I can tell you that the pro1 has a very minimal set of changes from the qcom bsp so it's probably using the default qcom USB compositions. Many device vendors customize these.

@Khalid I'll refer you to a post that I made a bit over a week ago: https://community.fxtec.com/topic/2809-after-a-solid-month-i-give-up-i-need-to-vent/?do=findComment&comment=45253 The tldr of it is that yes, FxTec nerfed the software and as a result they don't even really have control over the OTA contents or timing. Big mistake? Absolutely. End of the world? Not even close. Software will improve over time and there are alternative ROMs to choose from. Lineage, in particular, is now quite usable except for the notification light (which will be fixed in short

There are a variety of things that can hamper performance. You just need to go through them and find the one causing problems. The most obvious is the CPU cores: they can be disabled or thermal throttled for starters. Then there is performance stalls like for example audio or video timing out due to some problem. So unfortunately there isn't an easy answer. 😞

Try playing with the audio buffer sizes, and maybe diff 1+5 settings.

It's not so much a matter of the work involved. It would be very quick and easy to provide four sliders. But I think that makes the UI way too complicated. My criteria for options is not just implementing something that somebody wants or even needs. It is more like: (1) is this needed and/or reasonable? if no, reject. (2) is this something that everyone needs or is benign if always set? if so, just do it without an option. (3) make an option in the simplest, clearest way possible. I'll look into adding a visual indicator in the settings widg

Actually I think increasing the left margin when the slider is out might be a better solution. I'm just wondering if it should be a multiple of the user margin setting (1.5x? 2.0x?) or a fixed number.

I have a very early prototype that has reduced edge sensitivity... a built-in margin. 🙂 It also has zeros for IMEIs which makes it unsuitable for testing radio things. So I was provided a near-production prototype that has valid IMEIs and also better edge sensitivity. I use the earlier one for stock and the later one for lineage.

Okay I'll put that on my todo-list.

The keyboard driver only polls when at least one key is pressed. When no keys are pressed, it uses interrupts. So there should be little concern for the CPU usage. I could even get rid of the option and always use 20ms. I just preferred the longer delay because I could not detect any keyboard lag at all with 40ms. Also note that there is still one more optimization that I would like to make for the keyboard, which is a hybrid interrupt/poll mode. In this mode, the driver would only poll on the rows that have keys pressed (it is currently all-or-nothing). This would reduce the work

I believe there is supposed to be code to add those settings into the search results. But I just copy-pasted it from an example and I do not understand it at all. I can investigate. That is for the keyboard polling. When no keys are down, the keyboard driver relies on interrupts to detect key presses. But due to the way the hardware is designed, this doesn't work for certain key combinations when a key is already pressed. So, in order to detect two keys down at once, it is necessary to poll for changes. The faster you poll, the quicker the response time and the more

I believe I've found the issues with both the WiFi signal strength indicator and the notification lights. Both are broken because there are some Lineage specific changes that need to be applied to the kernel. So I'll try to get those working early next week. Details: The 1+5/5t (which is what I copied to start the pro1) has the WiFi driver built into the kernel and a couple other minor surrounding changes. The pro1 has the WiFi driver as a module (as the BSP does). The wlan sysfs node is in a different place for built-in vs. module, which is why the signal strength is broken.

You should see the options in the system section when you select "advanced".

A unique ID is generated at first boot after a wipe. When you opt-in to stats, it sends the ID and device model every 24 hours. I believe the page counts the last 90 days. So this is the count of active devices that are opt-in, with duplicates for each time you wipe.

Looks like we have quite a few lurkers... https://stats.lineageos.org/ 😀

I took some time today to organize the issue list, add labels, and such. Things are looking pretty decent. For example, here is what remains for parity with stock: https://github.com/tdm/android_device_fxtec_pro1/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3Abug+-label%3Astale

I hacked the FMRadio code locally to build. But I haven't pushed the fixes up to Lineage because it doesn't actually work. After investigating, I found that the QCOM BSP uses an entirely different FMRadio app and libs. Not sure how I'm going to handle that yet, so I've just left it as-is for now. The easiest thing to do is just what you've done -- remove the FMRadio package from the device tree.

I looked at the fingerprint stuff briefly today. Unfortunately most of it is closed source (even in the BSP -- the OEM tossed binaries into the device tree). So I need to come at it from either the kernel side or somehow override/shim the frameworks side.

test8 is up, you know the drill by now. * a2dp should be working. * Added touchscreen margin/deadzone. * Added settings UI for keyboard and touchscreen (Settings -> System -> Advanced). NOTE: if you use a custom keymap (looking at you @Craig) note the keymap file has moved. The reason is that /persist should only be used for things specific to the device that are invariant, eg. physical properties. So it is now read from "/data/system/keyboard/keymap". The file contents are the same, just "mv" the file over to the new location (creating the directory first,

Anecdotal evidence is never sufficient for something as critical as a filesystem. And I have another anecdote -- I worked next to Steve Kondik (the "Cyanogen" in CyanogenMod that preceded LineageOS) while Cyanogen, Inc. was a thing. One day he announced that btrfs ate the data on his laptop and vowed never to use it again. On the other hand, I have never experienced a single data loss event in over 20 years of using ext2/3/4 on many different devices (desktops, server, and laptops) that wasn't hardware related. Sure, if you want to use it and it works for you, go for it. And I

The BSP uses a feature called "split a2dp" and handles a2dp in the audio HAL. This is proprietary and does not work with the open source audio stack. So Lineage does not use it, a2dp is handled by the AOSP code. In order to make this work, the audio configuration needs to be updated. Because of the way audio works in pro1 vs. 1+5/5t, the audio configuration file is in a different place (/vendor/etc/audio vs. /vendor/etc). I neglected to update the correct file. As soon as I updated the correct file, it started working. There are a couple other related changes but that's the big one.

btrfs is not supported on android, neither stock nor lineage. It wouldn't be terribly hard to add it to lineage but the issue is nobody wants to use it. It's not been very stable in the past and so trust isn't there. Probably won't be for a very long time, if ever. If you want to get away from fat/vfat/exfat, your best option is probably ext4. Lineage has supported ext4 sdcards for just about forever.