EskeRahn

It might be so on other builds, but not on the official builds for LineageOS 16, 17, 18, 19, 20, nor AICP as far as I can see. (It might be inside payload.bin though) Here latest Lineage

We got no real info here, but we do know that many US carriers makes it it hard to do BYOD, so check with you carrier first, or be prepared to look for another carrier. There are some good info in this thread on what various US users have tried.

I have stopped expecting any logic here, though I still expect that I will get it at some point.

What they are now sending is the 8/256GB Blue QWERTY-EN, So those of us with more rare choices (like my Scandinavian keyboard) will have to wait further, despite having a number way below 568.

👍 (nor vice versa)

For those interested, the old: https://web.archive.org/web/20230227093209/https://download.lineageos.org/pro1

They changed the download site (this is Pro1, not Pro1X). As usual practically everywhere on the web these days to poor 'design' with extreme waste of screenspace. (see image below) And the recovery boot image now always have the name boot.img, so you would need to manually rename or move in subfolders to to keep pairs of files for later usage. (previously the recovery image were named e.g. lineage-20.0-yyyymmdd-recovery-pro1.img for 20.0 ) But it works as usual: (lineage-20.0-20230306-nightly-pro1-signed.zip on February 5 security patch installed smoothly using adb sideload and Mi

Sad to hear... But could it be that when it fails, it is actually failing trying to switch to another band? I so not know if it is possible as a user, but could be interesting to see what would happen if we could lock it on a single band only. (Obviously not a solution, but just to help debug the issue, by narrowing it down)

Oh I'm not saying that that is where I want the whole thing to be&go! BUT trying to be pragmatic, I would rather pay (even) more money than having a device I could not use, I would expect that -though far from all- some others might feel the same. It is not a matter of right or wrong here. Sure feel free to criticize all that went wrong, but venting our frustrations does not change anything. It is a matter of looking at the possible alternatives. Neither many with not working devices nor few with better working ones sounds good to me. Nor does shelling out more money of course. But if

Absolutely. but as other have it failing going from 20 to 3/1, and you see the complete opposite, to me indicates that it is the switching that could be the real culprit. Their communication has unfortunately always been sparse to put it mildly. So slim chances of them telling about work looking for the bug and/or looking for a fix. Once they told they are aware of the problem, the next we will hear is if (hopefully: when) they can offer something that improves or even fixes the bug. I have not got a clue on their financial situation, and have no clue on the resources allocated

That is a really interesting observation. And this points towards software/firmware and not hardware! I mean the most likely common denominator is that it works when not switching bands. So it could really be the band-switching that is flawed! That would explain why testing on different frequencies might have worked well, but real life switching could still fail. It might be under particular conditions or special pairs of bands - I have no idea, just guessing... If some carriers use mainly one band (at the least in some areas), we might not see it, but other carriers might rely more h

ADD: Just had the issue on the Pro1, and the workaround does NOT help here, so most likely two different bugs, though with same symptom.

Great that you found a workaround! And thanks for sharing, I will try that, the next time I get the similar bug on the Pro1. (At the least that unlock method works on the Pro1 too when the bug is not there) I got an early Pro1X unit from FxTec and a retail Pro1X bought from Expensys (still waiting on the super-early-bird one Perked for on IGG). And though I only use them for tests, I have not had fingerprint reader issues at all on these two (yet?) so I'm pretty sure it is not a general issue for the Pro1X. And as you still got see it on your factory reset unit, it should not be a

"2023022", same.....

(lineage-20.0-20230227-nightly-pro1-signed.zip on February 5 security patch installed smoothly using adb sideload and MindTheGapps-13.0.0-arm64-20221025_100653)

I have not tried a complete backup and restore, but you might get some interesting info from the remark on the Persist partition in the top of this.

Unfortunately I fear you got some hardware malfunction. If it was 'just' a software bug 'all' with a Pro1X would see the same.

For what it is worth, I can say that it is not a general issue on the Pro1X, so either you got something installed that does not agree well with the Pro1X, or you got a faulty unit. Does it work generally unlocking from screen locked state? Is the bug limited to in apps? My best - well least bad -suggestion, is to save all on the device, and do a factory reset. At first without restoring anything, to see if it works unlocking the screen in this state. If that works, we are looking at software-conflicts. If it does not work, we are looking at hardware-issue.

Note that the OP question was on the Pro1X, I was just telling that I have seen it on Pro1 too - I have not seen it on Pro1X -yet- though, but am not using it daily.

A similar issue exists on the Original Pro1. Occasionally it get into that state, and a simple restart fixes it. But the issue comes back. Sometime the same day, sometimes weeks after. I see no real system in it. Except I have a suspicion that touching the reader while it is vibrating a notification, triggers the odd state - though not always. Or maybe it is while it is still receiving an sms/email/call. Picking it up in an idle state to e.g. send a message does not seem to trigger it - or only rarely so.

(If anyone should be in doubt, the images are NOT Pro1/Pro1X)

Hard to say, but with some 'luck' it is limited to some soldering - but might well be easier said than done.

https://github.com/sailfish-on-fxtecpro1/droid-config-halium-qx1050/issues would be my guess, but there are other repositories that looks like qx1050 related here

AFAIK This partition contains specimen specific data that should not be used on multiple devices simultaneously. Hence it should not be shared, Perhaps Support can regenerate and push one matching your serial number? I tag @Casey to see if there is a way to get it?

As @claude0001 indicated it is not really clear who&what are affected. It seems like it can be related to LTE band 3 and maybe 1, but we do not really know. All we know here is that FxTec at some point said they could not reproduce the issue in the UK, but we have others that have reported it in the UK. So could be a mixture of carrier and region that are affected, Personally my 2019 Pro1 I use as a daily driver has a rather worn keyboard by now, but yet I have not switched to the Pro1X I impatiently bought from Expensys (still hoping to get one from IGG), I work primarily from home,