[Pro1-X with Linux]

1 hour ago, sspiff said:

I still have my Nokia N810 and there is no modern kernel that supports its LCD or graphics chip, unfortunately.

Thanks to MaemoLeste, the N900 can run a 5.x.y kernel now (I should try it at some point). However also here, they had to somehow reuse the original closed-source driver for 3D graphics, and sadly, also the remaining hardware is only mostly supported. And that is 13 years after the device was released ... Not to be misunderstood: the MaemoLeste people do great work here, they are just too late to the party. Pretty good illustration of my point above, about how obsolescence catches up with the phones before their support in mainline Linux matures sufficiently for being practically useful. 😞

[Pro1-X with Linux]

You are obviously very skilled with Linux and embedded systems. Sorry for spamming you with technical details on chroots and LXCs that must be completely clear to you. 😄 Hopefully my post can still serve to encourage others who just want to run a GNU desktop environment on their handheld without sacrificing regular smartphone capabilities ...

All your points a perfectly valid, and I couldn't agree more that support in upstream Linux should be the ultimate goal, always. Unfortunately, the mobile phone world being what it is, this often means that the hardware reaches obsolescence before it is supported in a way to be practically useful. So us, who want to actually also use their phones, have to settle for pragmatic solutions like chroots ...

1 hour ago, sspiff said:

I've also been an embedded Linux developer in a past life, and I remember the pain of having hardware, compilers and kernels frozen in time forever (remember how long some platforms and distros stuck with Linux 2.6.32?)

This. I came to the Pro1 from an N900. Loved everything about it, but in 2020, we were still camping on 2.6.28 as some driver modules had never been open-sourced by Nokia ...

[Pro1-X with Linux]

9 hours ago, sspiff said:

I received my Pro1-X last week but would kill for a real pocket Linux experience on a keyboard phone (rather than containers on Ubuntu Touch or Sailfish, or Termux or whatever on Android) [...]

If you want to run mainline Linux out of principle, I totally respect that. 👍

But, on the practical side: what do you think you would miss if you ran your favourite GNU distro in a container of Android, Sailfish or UBTouch, as proposed by @matf-kabouik or @Rob. S.?

Many think of an Android/Lineage chroot or an UBTouch/Sailfish LXC as an "emulator" or a "virtual machine", and therefore have the gut feeling that any software installed in such environments would not be "really" running on their phone. That its speed of execution would be slower compared to the "host OS". That it would somehow not give you that "bare-metal experience".

None of this is technically true. A software distribution in a chroot runs natively on the given hardware, sharing the single Linux-kernel (in this case: the one of Android) with the "host OS". If the device is rooted, you have access to any (hardware) interfaces exposed by that kernel. All the chroot does is isolate the "guest OS" on the level of the filesystem, so it cannot accidentially modify files belonging to the "host OS". Otherwise the two run side-by-side. From a rooted GNU/Linux-chroot on Android, you can see Android processes in top, and actually manage them using tools like kill (whether or not this is a good idea)!

LXC is an expansion on the chroot concept, also securing the "host OS" against intentional (malicious?) modification by the "guest" and seperating the two environments also on the process level. Otherwise, also software in an LXC is being executed natively by the kernel of the "host OS".

As also @matf-kabouik pointed out, it is true that there are some limitations regarding hardware access. However, per se, this is not an consequence of running in a chroot/LXC. Rather:

1) Either, the given interface is being blocked permanently by access from the "host OS". This is the reason one cannot access an Android phone's built-in audio devices via ALSA, while access to a USB sound card sometimes works.

2) Or, the Android kernel does not implement some interface expected by "desktop" Linux software in the first place. This is why it is so difficult getting HW-accelerated graphics in chroot/LXC containers. The kernel and device drivers -- targeted at Android -- simply do not implement the DRM interface expected by MESA/Wayland/DRI as commonly used in desktop Linux workstations.

[Pro1x - really poor connectivity to both wifi and cellular.]

1 minute ago, EskeRahn said:

If I travel without turning WiFi off, I will get spontaneous boots at what seems like random points.

Never heard of that -- but then I've also never used stock Android 9. I tend to view this anecdote as proof of how much the Pro1-X (too) will leave its initial (software) problems behind once we see LineageOS up and soaring ... Firmware bugs are a different story, of course.

[Pro1x - really poor connectivity to both wifi and cellular.]

3 hours ago, toast said:

I cant imagine having spent 2 years waiting and having paid close enough to 1000€ for what would basically amount to a hightech brick, would the connectivity be as bad as some describe it

I would advise you to relax. I guess, much of your first impression is determined from what other phone you come from.

I asked, and @EskeRahn reported a direct comparison of the Pro1-X and Pro1 above, which I interpret as "on-par-within-the-measurement-uncertainty". @Rob. S. reported similarly in a different thread.  I own only a Pro1, and was never super-happy with its WiFi or LTE connectivity, but it has still been perfectly usable over the last two years. So, in your place, I wouldn't worry too much about that point right now.

[Pro1-X with Linux]

9 minutes ago, toast said:

I dont recall the saying he was going to specifically work on the Pro1X? Or am I remembering incorrectly? Would be very happy to be proven wrong 🙂

I do not know anything more than was in the September 2021 update:

Quote

Angelo [...] will work as our in-house engineer for Linux and mainline support, as well as adaptations and functionality of alternative OS’s for your devices.

Note the generic "your devices". As I own only an original Pro1, I would be quite happy if it was still given some (official) love, too ... 😉

On a more serious note, they probably hired him for his general skills in embedded ARM Linux systems, and will want to flexibly adapt his focus according to company needs (which makes perfect sense to me).

[Pro1-X with Linux]

No one will have experience with those, as the Pro1-X was released only a few days ago.

For the Pro1, some success in mainlining has been made, resulting in (as far as I know) a PostmarketOS proof-of-principle. However, as the Pro1-X ended up being a totally different machine, nothing of that is likely portable easily.

On the bright side, F(x)tec hired a software engineer specifically to help in mainlining the Pro1-X (and also the original Pro1, I guess).

Just now, Adamyno said:

Is there no way to post-load the modules into the kernel to run on the device? (e.g. with modprobe)

The Pro1 and Pro1-X are not even using the same kernel, so even in the (standardized) x86-world, this would not be possible for binary drivers.

[Pro¹ X camera issues?]

6 hours ago, Rob. S. said:

A full-resolution readout would not make much sense, as the colour matrix only has 12 million colour squares, each one covering an array of 2x2 pixels. (There are few phones with 12/48 MP sensors which make an exception, though, and try to make 48 MP results available, too.)

Thanks for information and for summarizing this so nicely. I guess, most people are not aware that the typical camera sensor uses only a fraction of its pixels for each of the red, green, and blue colour channels, respectively. I also agree that, at the given size of phone sensors and lenses, and given the high density of a 48-megapixel sensor, just grouping pixels 4-by-4 is likely the most reasonable thing to do, except (maybe) for the most high-end phone cameras.

That said, it is also true that, in the days before CCD/CMOS sensors reached today's insanely high pixel densities, demosaicing, i.e. the (attempted) reconstruction of an image at the full pixel resolution of the chip by interpolation of colour values, was commonplace. At the time, it was standard for a "6-megapixel" camera to actually also write a 6-million-pixel image file to disk, even though each of the red, green, and blue sub-pictures had only some fraction of that resolution. Given how little this was "advertised" at the time, it's no surprise people nowadays wonder where their resolution has gone ... 😄   

[Pro1x - really poor connectivity to both wifi and cellular.]

WiFi and LTE connectivity seemed quite bad to me already for the original Pro1.

With reports about bad network quality of the Pro1X accumulating here, is there anyone who can compare the two devices side-by-side?

Edit: Re-reading the thread, I found that @matf has reported similar signal levels for his Pro1 and Pro1-X. Both phones have metal bodies that are certainly not helping their radios. Is this a real problem of the Pro1-X or are we chasing a ghost here?

[Got my Pro 1 X (thoughts below)]

@asonix I generally agree with your criticism and have pointed that out myself already in Pro1 times: F(x)tec enjoyed all the noise about the Pro1 being a "Linux  phone", a "successor to the N900", etc. However, all they really provided was a factory-unlocked bootloader and a plain, commercial Android OS.

Now, to be fair, they finally did hire a programmer specifically to contribute to the porting efforts regarding LineageOS, UbuntuTouch, and Mainline kernel.org earlier this year (was in one of the updates). So things are changing for the better ...  

[Pro1 X arrived but does not boot?]

47 minutes ago, Spargeltim said:

its on charging cable now since 1hour

From what others wrote, out-of-the-box, the Pro1X is not configured for charging in powered-off state (was the same for the Pro1). So keeping it connected to the charger will not fix anything if the battery is completely depleted.

The phone should ship with a half-charged battery and ready for action. I think you should contact support.

[Pro1-X off-line charging]

Indeed, the device needs to be in fastboot mode for fastboot commands to work. 😉

The alternative method of activating that mode is by holding "Volume down" + "Power" when switching on the device.

[Pro1x with SailfishOS]

13 hours ago, matf said:

Meanwhile, my old container works [...]

Congrats. And very interesting desktop setup! I start to understand what you meant when you wrote it is optimised for operation via keybindings. 🙂

As you have the same setup on both devices (Pro1 and Pro1X) now, can you say anything about performance?

In the past we worried a lot about the Pro1X's slower CPU (after its re-design). As, in our Linux containers, we rely on all-software rendering (llvmpipe) there could be a significant difference e.g. in OpenGL benchmarks or video playing ... 

[Pro1-X off-line charging]

I do not know about the Pro1-X, but for the Pro1, the command to enable charging when powered-off was

fastboot oem off-mode-charge "1"

[PRO¹-X: Two step camera button or single step camera button?]

On the Pro1-X spec page it says "2-stage camera shutter key", just like for the Pro1.

@EskeRahn is right: I also cannot feel the first stage of the button on my Pro1, but it does work in principle.

[Pro1x with SailfishOS]

1 hour ago, matf said:

If this was my issue, I would assume that newly created containers would equally fail to show in an X window, but they don't.

Ah, I had missed your point above where you wrote that your problem is limited to the container you ported from the Pro1. Never mind then.

If it is only about transferring your software configuration to the Pro1X, would it then not be easier to just install a fresh container and scp any relevant things (like $HOME/.config/) over from your Pro1?

[Pro1x with SailfishOS]

14 hours ago, matf said:

I have a VERY configured LXC container from my Pro1 that I can use and attach on my Pro1x, but so far I haven't been able to start X on it.

In my LineageOS chroot, I encountered the problem that X.Org insisted on having access to System-V-style shared memory, but that the Android kernel implements only "Google-style" shared memory (/dev/ashmem).

In my case, I could solve that by wrapping the android-shmem library around X.Org, as explained in this post.

Out of interest: Does SailfishOS natively support SysV shared memory calls? After all it also uses the Android kernel underneath.

[Pro1x with SailfishOS]

7 hours ago, matf said:

Then in my opinion you also need some configuration inside the container to make it really convenient for the small screen size and to use keybindings as much as possible instead of touch (see what I did with my Pro1 for instance: search on Youtube for "Pro1 SaiilfishOS LXC" ...

This, 100%.

Imho, configuring your 'containered' (desktop) GNU/Linux distro in a way to make best use of the small (touch-)screen is a large part of the work. That is, if you want to actually use the system productively rather than just show-off your neofetch output online to your friends once ...  😉 .

Trying to operate applications designed for desktop workstations via a touch interface can be frustrating even on a full-size display. On a small handheld touch-screen, the experience can quickly become infuriating, unless given some significant GUI customization.

In my setup (based on LineageOS, but that does not matter here) I solved this pragmatically by running the X11 server of my desktop Linux distro inside XRDP. That way, the container'ed GNU/Linux desktop can be accessed via remote-desktop apps running on the host OS (Lineage, Sailfish, etc.). Such apps typically allow for emulation of a virtual mouse pointer, with the Pro1(X)'s screen acting as touch pad. This saves you from having to hit minuscule buttons with your fingertips. Also things like pinch-to-zoom are natively implemented in most smartphone RDP clients. Similar results can in principle be obtained via VNC. I prefer XRDP, as it also does automatic session management in your GNU/Linux OS for you.

The downside is that, because of the additional remote-desktop layer (requiring encoding and decoding of the framebuffer) graphics performance is significantly worse compared to using an X11-server that runs natively on the host OS (as proposed by @matf).

[I got the Pro¹ X in the mail earlier this week and I need help]

9 hours ago, JECE said:

It's a bit concerning to learn that even on LineageOS proper smartphone keyboard typing seems to be limited to only a subset of apps.

I tend to disagree with that. The more you are trying to use the Pro1(X) as a "real" computer terminal, the more you are going to be irritated by "Android" features suddenly popping up in your face.

For me, the accent selector does have its use in some apps targeted at more casual writing. But, e.g., when coding, I often write sequences like '<<<<<<<<<<<<<<', '>>>>>>>>>>>>', '++++++++++++++', or '--------------------' when commenting programs. In these cases, I find it very helpful that my text editor (acode) does not bring up the respective accent selector boxes ('≤, «, ‹', '≥, », ›', '±', or '-, _', respectively) upon me holding down those keys, but instead autorepeats the symbol exactly as I typed it on the keyboard.

I guess it is a matter of use case. So, I think it is good that apps can opt to support or ignore that feature, as that also gives you the possibility to choose according to your needs ...

[I got the Pro¹ X in the mail earlier this week and I need help]

22 hours ago, JECE said:

How do I access accented letters on the physical keyboard? Holding down a letter just repeats that letter over and over (e. g., "eeeeeeeeeee").

Try to test with different apps. On the original Pro1 (with Lineage 16.0) long-pressing a physical button worked for bringing up the accent selector box, but only for certain apps. For me, it works in what I call "smartphone-typical" apps like QKSMS or the Settings Menu. It does not work in some apps that are more serious about physical-keyboard typing, like, e.g. CollaboraOffice or ConnectBot.

I guess apps can opt in or out of that feature, which I think makes some sense: depending on context, users might expect a long-press to auto-repeat the character rather then to bring up the accent selector.

edit: The above applies equally to the sticky-shift feature. It works on Pro1 (LOS 16), but only for apps that choose to support it (the divide seems to be the same as for the accent selector box).

[Working ROMs for the Pro1]

I remember a post by @tdm which said the telephony driver bits in LineageOS were unchanged with respect to Stock Android 9. Considering that enabling VoLTE et al. for a given device is up to the carriers, is there any reason to believe that installing (whatever version of) LineageOS would improve anything here?

Screw this. I should have followed @EskeRahn's link above which shows that going from Stock to LineageOS did enable VoLTE for him. Lesson learned.

[Backing up bricked phone...]

On 7/11/2022 at 4:31 AM, Joey said:

I put trwp on there and it can't see the normal mounts for internal storage so I can't even back it up.

As far as I know, the version of TWRP available for the Pro1 does not support decryption of data partitions and hence cannot be used for backups. In fact, the only purpose of that build of TWRP was to enable a clean install of SailfishOS. It is also known to mess up the existing data partition upon boot: https://forum.xda-developers.com/t/twrp.3976369/ , https://community.fxtec.com/topic/2479-team-win-recovery-project-twrp/

[PRO1, AICP 16.1 (Android R) Official Build]

On 7/6/2022 at 4:07 PM, Hook said:

There is someone here who is unofficially maintaining Lineage OS 16, keeping it patched every couple of months (He runs it Google-free, but no reason you can't add Gapps).

Thanks for mentioning my LOS 16 builds.

For completeness: @daniel.schaaaf maintains an unofficial ROM of LOS 17.1 (Android 10) for the Pro1.

In principle, the sources of all four LOS branches (16.0, 17.1, 18.1, and 19.1) are still maintained at lineageos.org and are getting patched based on the Android security bulletins.

It is only that - by LineageOS policy - only one branch per device (in our case 19.1, now) is allowed for the automatic weekly builds, probably in order to save CPU time on the official compiler farm. It is however totally possible to build any of the supported branches of LOS yourself, in which case all upstream security patches get included automatically ...

[Pro¹ X – state of production and delivery]

2 hours ago, EskeRahn said:

So why do you find it crazy that they have not updated after one week ?

I guess some have developed such passion in ranting about F(x)tec that they will feel empty and disappointed when they receive the phone after all ... 😉

[PRO1, LineageOS 16.0 Official Builds: Discussion]

On 6/22/2021 at 8:15 PM, claude0001 said:

http://findus.zwergenschaenke.net/~puma/linux.html#lineagepro1

I uploaded my latest LOS 16.0 ROM, dated 20220530.

It contains the 5 April 2022 AOSP fixes. There are no other changes since my last build above. As usual, a tar.gz with all my local mods with respect to the official lineage-16.0 sources is also available.

I had originally intended to skip the April patchlevel, and jump directly to May 2022. Unfortunately, there seem to be problems with the May patches for some other device, hence they have not been merged into the official tree yet ...