claude0001

In LOS 16.0, there is a setting "System > Gestures > Jump to Camera". Enabling that causes the camera app to launch when the power button is pressed twice. Not sure that feature exists in later LOS versions, but if yes, you might want to make sure it is disabled. Otherwise accidential double-presses of the power button might indeed cause the behaviour you observe.

The thread you are looking for is here: https://community.fxtec.com/topic/3204-display-units-with-large-tap-insensitive-margin/page/9/ However, I do not think we had a case of Pro1-X with this problem yet. For the Pro1, the usual fix was to flash back to the initial stock (Android 9) OS. Not sure it works similarly for the Pro1-X ...

I'm a big fan of LineageOS. But for completeness, let's mention that there seem to be some apps that refuse to install and/or run on LineageOS, because they identify the system as "unsafe" (unlocked bootloader and all that ...). Yes, it is nonsensical to consider stock Android 9 -- with by now hundreds of unpatched security holes -- as "safe", but, apparently, that's what they do ...

The FP3 also has an LCD. But especially at low brightness it looks way better than my Pro1's AMOLED. Also: No f**ing rounded edges! 😄 It's not all in spec sheets.

Dear @Slion, I think I've got an idea how you are feeling. While I haven't retired my Pro1 yet, I also use the HW keyboard less and less. Partly, this is because some keys are becoming more and more unreliable, which makes typing a frustrating experience. Mostly, however, my use cases for the keyboard are much fewer than I had initially expected. I came to the Pro1 from an N900, which had an OS and an app ecosystem that was designed around landscape use of the phone. This is simply not true with Android. While almost all apps support landscape in some way, few make intelligent use of

If the issues are software-related at all (which has not been proven), it is reasonable to assume that the bugs are in the drivers and/or their firmwares. Those bits are closed-source and cannot be fixed by LineageOS. They just re-use them 1:1 from stock.

No, we don't. What we do know is that F(x)tec have been struggling to fulfill the pending orders and IGG perks for the better part of a year, and the situation does not seem to clear up. The phone might eventually become reavailable for purchase from their web store, but I wouldn't hold my breath. That being said, quite a few phones have been delivered (though mostly not by F(x)tec), and unboxed-but-unused Pro1-Xs pop up on ebay all the time. So it shouldn't be that hard to get one if you really want it. Then again, you might ask yourself why the Pro1-X is easily available on the sec

As @Sean McCreary clarified in the LOS 20 thread, off-mode-charging cannot actually protect you from the battery-depletion-bug. The Pro1X's (and likely any other Android devices's) charging is controlled by the OS in all cases. Seemingly, this means that some minimal amount of battery-charge is always required to boot the OS to the level where power-supply can be actively handed-over to a USB-connected PSU - irrespective of whether only the "charging screen" is loaded, or the full Android/Lineage GUI. Do not ask me why things are designed this insane way. It just seems to be the reality

@SchattengestaIt Those are amazing hardware hacks. Many thanks for sharing! We're slowly getting to where the maemo.org forum left off ... 😉

I had been suspecting this was the case for some time now. Thanks for clarifying. This means that off-mode-charging cannot actually protect us from the battery depletion bug. If the battery is flat, it's game over, irrespective of the off-mode-charge setting. Thanks, it is clear to me that LineageOS cannot fix those bits. Does anyone know whether F(x)tec actually have the sources? I.e. can they fix these things in house or do they rely on some external software company for maintaining the stock OS and its drivers?

That variable has nothing to do with individual signal levels. It works in conjunction with the INTERMEDIATE_POS=1 setting, and causes also the very early iterations of position estimates to be reported to client apps as a "fix". The unit of ACCURACY_THRESH is meters. Setting it to 3000 means that early position estimates are reported, even if they are still uncertain by 3 km. However, to my knowledge, the variable does not actually influence how the iteration towards the final solution for the position progresses. To me, the fact that @Name_not_avail saw their phone getting the fix

So ... I recharged my Pro1-X battery using a laboratory power supply after it had depleted completely, probably due to the "battery protection bug" mentioned by f(x)tec in their updates. It turned out that the most difficult part in this is getting to the battery. The Pro1-X is not nearly as "serviceable" as I expected. Separating the different parts of the body is not as easy as the instructional videos suggest. Also, the battery itself is glued into the phone, which makes its removal a scaring endeavour. Note that removing the battery from the phone is not strictly necessary for re-char

So ... in case you want to relive the good old days with the Pro1 (SD835 only!), LineageOS 16.0 just got another update. At https://findus.zwergenschaenke.net/~puma/linux.html#lineagepro1 fetch the ROM dated 202304024. It gives you backported ASB patches up to 5 April 2023. There are no other changes compared to last month's release. Refer to my tarball of localmods for the full list of code changes with respect to upstream LineageOS 16.0. Have a lot of fun.

OK, fixed it. Prawn-X is back alive! 🥳 Turned out the battery was completely flat. After disassembling, I measured 0.00 V between the pins! I do not know how that happened, maybe I did accidentally leave the device on when putting it away. Still, I'm pretty sure the battery should never discharge to 0 V in any design scenario, as the device should automatically switch itself off before. I guess this is related to the "battery protection bug" f(x)tec keep mentioning in their updates ... Anyway, I was able to charge the battery to ~50% (3.9 V) using a laboratory power supply. After tha

I fixed similar problems (in Germany) years ago by having the following changes in /system/vendor/etc/gps.conf: [...] XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin [...] XTRA_VERSION_CHECK=1 [...] NTP_SERVER=europe.pool.ntp.org [...] INTERMEDIATE_POS=1 [..] SUPL_HOST=supl.vodafone.com SUPL_PORT=7275 [...] since then, GPS has been working quite OK for me (I have no Gapps on my Pro1). Changing that file in LOS 20 probably involves Magisk scripting, which I unfortunately have no

I confirm that installing Lineage on Pro1-X breaks offline-charging-mode. I had that enabled and working successfully on 2.1.5-GMSless, but never checked after installing LineageOS. I am not on one of the official builds, but on one of the betas from few weeks ago. After reading this, I tried to charge my Pro1-X (shelved for several months) and it seems to be bricked. Upon connecting the charger it briefly blinks red, but then nothing. Previously (with 2.1.5.-GMSless) it would charge (while displaying the "battery screen"). Well ... what to complain about with such a broken device ..

No offence, but, in your report, you are doing precisely that: whitewash a faulty device. Your LTE-router workaround is technically interesting, but it doesn't mitigate the Pro1-X's failure as a mobile phone.

I agree that the Pro1-X's keyboard is better than the Pro1's. But, yes, for me the whole point with the Pro1/Pro1-X is to carry around only the one device I need anyway - my phone. A single device that works as a normal Android slab most of the time but can transform into an UMPC if I urgently need to get some stuff done while away from a real workstation. If I were to settle for carrying two pocket-sized devices all the time, I'd probably choose something else than a Pro1/X as the "computer". I think there are far more capable miniature laptops. But, honestly, I think this discussio

Forget it. People from all over the world have been reporting those network problems for 8 months now. At one point @Casey even acknowledged that this is one of the most reported issues. Still, they haven't come up with even a glimpse of a solution. I think the two most likely explanations are: 1) Something is systematically wrong with the qx1050's RF hardware, causing it to fail in many regions/networks. 2) There are a lot of defective devices around, as @Rob. S. suggests. Either way, f(x)tec will not have the (financial) means to fix all those devices. All they can do is keep affected c

The unofficial builds of LOS have been available for some time. While it is great that they are now to become official, for me, they unfortunately never made any difference with regard to mobile connectivity. Note that does not necessarily mean its hardware issues. LOS has to use the closed-source driver blobs from stock firmware as-is. If the bugs are in there, they couldn't fix them even if they wanted.

Sorry, but this does not make sense to me. For me, this entire discussion started with you trying to fix a broken build of AICP precisely without recompiling its source (as others would have done). Rather, you tried to substitute-in the boot partition from another build in binary form, hoping that would magically fix things. Do you personally know the AICP developers? For the Pro1? I do not think so. You simply trust that project because it's open-source and others trust it. That "toss-salt-over-your-shoulder-and-hope" approach is quite common. And we both use it. Strangely, that seems to

Eske, I usually wouldn't care. But as you are a moderator on this forum, I would really like to know how I deserve this kind of hostile response to (what I intended to be) a helpful post. I linked to the github main pages of those two projects. They provide project descriptions, source-code (as you noticed), how-tos, instructional videos, and official (not "random") downloads of binaries from their release branches. I think that is a pretty transparent and widely accepted way to link to an external open-source project. None of the *.exe's need to be "installed" by the way - they run right

So why then make fun of my proposal and wrongly suggest it requires you to install a GO interpreter? (Something I am not sure even exists, I believe GO is meant to be a compiled language.)

Did you even follow the links I posted?! Both of them give you portable Windows *.exe's (along with builds for other OS) that just run on any random box. No one expects you to compile the code yourself. When I say "no dependencies whatsoever", I mean it. Was actually trying to help ... 🙄

😄 ... as I already hinted above, you could have avoided python and git -- and thus most of those tedious steps -- by using one of the standalone extractor tools I linked to above: I just tested payload-dumper-go. It works well and has no dependencies whatsoever.