claude0001

No, don't think so. Also the device-specific code has distinct branches for 16.0, 17.1, and 18.1. That patch of @tdm is proposed against 18.1. So if it is accepted, it will be only in there. Currently the driver in 18.1 is still (almost?) the same as in 16.0 and 17.1 so backporting the patch to your local 17.1 tree should be trivial. That may change in the future, as there are several proposals for improving the keyboard driver in 18.1. I am loosely following that development, but almost certainly will not backport everything to 16.0, as I am in fact quite happy with the current

Try to be optimistic. Money is not everything. I paid my Pro1 (without the "X") also more than a year before I finally got it. Now that I have a real keyboard phone, I congratulate myself for the decision to preorder every day.

Build 20210922 is available. It includes the September 5 AOSP security fixes. As of this release, the build includes a backported patch, originally made by @Slion for LOS 18.1, which allows one to use "Fn-Tab" and "Alt-Tab" equivalently for switching Apps (see this thread). I find that feature really useful when holding the Pro1 by the keyboard. I have used that modified keyboard driver for weeks without issues. Still, be warned that this code has not been merged into any official LOS branch yet, and should thus be considered experimental. Edit: I think I should clarify:

I like those news in particular ... 😺

While I agree with most of your ideas, I think that ship has sailed. According to the last update from Fxtec, they should be in the protoyping phase by now. Even small changes to the hardware would likely introduce large delays at this point. As @VaZso pointed out, that's especially true for the Fn key which is wired differently than "normal" keys. So it is not only a matter of changing the printing on the caps. That said, I would not worry too much. My experience is that typing on the phone and on the PC "feels" so different that it does not help to have identical layouts for the symbols

Exactly. Out of interest, I had applied the proposed patch to my LOS 16 on my QWERTZ Pro1: The respective key immediately stopped working correctly. With @tdm's default keymap, things have always worked - given the correct configuration you describe. That one has to configure things in two places is of course a little cumbersome, and many of us QWERTZies stumbled on that in the beginning. Streamlining the UI here would be nice, but also not strictly necessary, as for most users configuring this is a one-time action.

Since I have never had stock, I cannot compare LOS to it regarding call quality. But I somehow remember @tdm saying the telephony bits were taken 1:1 from stock, so maybe there really should not be much of a difference ... All I can say is I'm happy with the few phone calls I make. Yes, sometimes I adjust the volume during a call, but no idea if the Pro1 is to "blame" in those cases, or whether it is my partner's phone. That said, I am probably the wrong person to ask, really. I have accepted the fact that reliability and audio quality in telephony reached its peak around the time of the

I was asking about the patch being "cosmetical" because in the commit message of the patch it says: (emphasis mine). Actually the patch cannot be directly used in LOS 16.0 because more entries (related to the use of PowerHAL in later releases, I guess) have beeen added meanwhile. Anyhow, I backported the change from '44 -> 2c' to a test build of LOS 16, and that has been running normally on my Pro1 for two days now ... Question is, should there be any (net) effect of this change (e.g. regarding power consumption), or not? 🤔 Yes, that one was clear to me. Thanks for the

Should this fix actually be backported to 17.1 and 16.0, or was it purely "cosmetical"?

Had not tried that. I confirm that recording from my 3.5-mm-jack headset does not have the background-filtering problem. However, recordings done that way have a low-volume (but clearly audible) "klicking" background (~2 Hz). Attached is a sample of that. Does not happen with the built-in mic (where it is probably suppressed by the filter). So, indeed it is better, but (for me) no ideal solution either. 2021-09-09 23.27.25.wav

The Pro1 seems to do quite aggressive background suppression when recording from the built-in ADCs, no matter what specific audio source is selected. For normal voice recording, this actually works quite well for me. But I do believe this is what prevents you guys from recording music with the built-in mics: Depending on the tone and loudness of a particular part of the track, the filter takes the music for background noise and suppresses it. In fact, I think I can produce these artifacts even when I try to record myself singing (though normal speech works well). And, no, I will not uploa

Nope. I underestimated OSMAnd~ (again). 😄 One can indeed activate "Snap to Road", however that is active only during turn-by-turn navigation. Not when just recording or monitoring your position while you move around freely.

True. But I regularly record GPX tracks of my hiking or biking tours with OSMAnd~, and they are always "noisy" and little "off" the road, so I believe it does not do such things.

Be remined that the accuracy reported by the phone is just an estimate. Even under optimum conditions, the true position deviation can be significantly worse than the reported estimate, as e.g. this study found. In particular, the authors show that phones can, both, over- and underestimate their precision, and that models reporting better values may in fact have larger deviations in reality. If surrounding structures (e.g. tall buildings) introduce systematic errors the receiver cannot sort out, these deviations can probably be much larger still. My personal experience largely a

You can, with fastboot. fastboot --set-active=a

As you know, I feel the same. But in all fairness, let's say that Lineage is not actively going that way. It simply maintains compatibility with the respective Android release, which does make sense, right?

I can confirm that the category "optimisation not available" exists on Lineage 16, too. Though I have only a handful of system Apps, mostly related to telephony, that fall into it. Specifically, my GPS App (OsmAnd) is listed as "optimised".

@Slion I understand this was missing in the original patch. Could that explain what you observe?

I have an ext4 partition on my SD card and it is recognised by Android. I did partition and format the card using my Linux PC, not from the Pro1, though. Beware that many Android Apps will have problems accessing the ext4 partition. A file manager with root access will work, but many "normal" Apps won't. After some months, I found that disabling SELinux at boot time and re-mounting one of the many cryptic mountpoints of the SD partition allows one to use it almost normally from Android. I described that in this post. Of course one may want to think twice before nuking SELinux as that disa

I never had Gapps installed, but I am pretty sure that at the time LOS 16 was in testing phase, @tdm always reminded people not to forget to reinstall them after flashing a new version via sideload.

Isn't that to be expected? I also have to re-sideload AddonSU each time I flash a new ROM.

For me (on LOS 16) sideloading my custom ROM from the official recovery would just fail (without anything getting flashed), so I am not sure if this is the same phenomenon.

Yes, that's the correct procedure, which worked for me since I got my Pro1. Upon flashing the ROM it switches the active slot. A reboot is then needed to make sure any additional software is actually sideloaded into the right OS.

You mean sideload your own build over an official one? That will only work without wiping data if you migrate your setup from 'official' to 'testing' keys. Also, at least for LOS 16.0, the official recovery would not allow me to sideload my own build. I had to first flash my self-built boot.img using fastboot (to both slots, just to be sure 😉).

No, I do not think so. As far as I know, the "testing" keys are not unique to a certain building environment, so you should be able to flash the new build over the previous one without migrating. Did you actually solve that issue you had with installing Gapps and other Apps on your custom build?