Jump to content

claude0001

Members
  • Content Count

    418
  • Joined

  • Last visited

  • Days Won

    50

Posts posted by claude0001

  1. 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?

  2. @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 ...  

    • Like 1
  3. 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.

    • Like 1
  4. 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 ... 

    • Like 1
  5. 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?

    • Like 2
  6. 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.

    • Like 1
  7. 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).

    • Like 1
    • Thanks 1
  8. 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 ...

    • Like 3
  9. 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).

    • Thanks 1
  10. 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.

    • Haha 1
  11. 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/

  12. 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 ...

    • Thanks 4
  13. On 6/22/2021 at 8:15 PM, claude0001 said:

    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 ...

    • Thanks 1
  14. 9 hours ago, silversolver said:

    Anyone have a link to the last 17.1 for Pro1 that still works?

    Lineage purges old builds as they do not want to promote the use of outdated (and thus unsecure) roms. It is however totally possible to build all supported branches (16.0, 17.1, 18.1, 19.1) yourself, in which case the latest security patches from the upstream Android project get included automatically. Such builds are then "unofficial" in that they are not signed with the keys of the Lineage project, but otherwise they are based on the same source code.

    @daniel.schaaaf maintains an unofficial lineage-17.1 rom for the pro1. See this thread.

    Myself, I maintain an unofficial lineage-16.0 as documented in this other thread, if you prefer to stay on 16.0.

    Both roms are quite up-to-date with the latest Android security patches, though I must admit I haven't had time yet to build mine with the May 2022 AOSP patches. They also include a few improvements related to the keyboard driver we backported from 18.1.

    • Thanks 2
  15. 2 hours ago, kashif said:

    it works fine with pro1 and i get very good speed as well.

    Interesting. Did you actually measure the data rate?

    As I wrote above, I am stuck to around 200  Mbit/s with my UGreen ethernet, which is slower than the Pro1's wifi (but of course still fine for all everyday tasks).

    • Like 1
  16. LineageOS 16.0 is basically Android Pie with the proprietary Google stuff removed. The Linux kernel is identical to the one shipping with the Pro1's Android OS. As it is the kernel that is doing all the hardware support, I would thus assume that a device that works in LOS 16 should work in Stock Android, too.

    But, no, I haven't tested it. Sorry.

    • Thanks 2
  17. I have got this combined card-reader, USB-hub, HDMI-adapter, and ethernet card:

    https://www.amazon.de/-/en/gp/product/B093FKT9BF/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

    All features of that hub work out-of-the-box in LineageOS (16.0 over here, still).

    That said, performance-wise, the Ethernet adapter does not even remotely reach the advertised 1 Gbit/s: iperf3 measures ~150 Mbit/s up and ~230 MBit/s down. On the same network, with the same peer, I easily get 300-400 MBit/s via the Pro1's WiFi ...

    • Thanks 2
  18. 1 hour ago, toast said:

    was hoping to format it to ext4 as well

    Be aware that, as part of its security concept, Android runs every app under a different UID. As a consequence, with an ext4 FS, data sharing across apps can be difficult unless they use the common GIDs (media_rw, etc.) foreseen to that effect. In the past, many people used FAT-formatted SD-cards to circumvent that restriction, taking advantage of the fact that FAT simply does not know about UNIX file permissions. I do not know if this affects your use case(s).

    • Like 3
  19. 2 hours ago, toast said:

    Also, does the FAT32-only apply to all available ROMs, or only stock Android?

    I do not know about stock Android, but on LIneageOS (16.0) I have two partitions on my SD-card: one formated as ext4 and one as ext3, and both just work. I did the formatting externally using a PC. The same card can also be accessed via an external (USB) card reader connected to the Pro1, so this is independent of the built-in reader. At least on the low level, I think the kernel supports all filesystems it is aware of, irrespective of the specific block device.

    Of course, how Android treats a partition on the high-level may be a different story. On my Lineage 16 (Android 9), I can use my ext3/4 SD partitions normally from standard Android apps once I identified them as "portable storage" upon first detection. However, this may have changed in later versions.

    As for the I/O-performance of the reader, I do not know, neither for my Pro1 nor for the Pro1X.

    • Thanks 1
  20. 12 hours ago, EskeRahn said:

    ...I wish they would offer the usb-board as a spare, e.g. on IGG, I would certainly buy some, as this always is a vulnerable part of any phone expected to have a long life.

    This.

    I recall they designed the Pro1 specifically to have the USB port on a dedicated board (and thus easily replaceable) as the USB socket was a well-known weak point of the N900 (where it was directly soldered to the mainboard). But without spare parts, that design effort was futile at best ...

    • Like 2
  21. 2 hours ago, matf said:

    I've tried that on SFOS too to cope with the lack of video out, but (1) performance was bad,

    Probably depends on what you compare to. Intuitively, it seems clear to me that rendering on a remote client must have better performance compared to running the client on the localhost.

    Anyway, most of the time, I use my Devuan chroot remotely via SSH. While LineageOS has its own SSH server, I agree that its CLI is much too crippled for daily use. I thus configured Devuan's SSH server to listen to the default port 22 of the Pro1, while relocating LineageOS's SSHD to port 222. That way, the latter can still be used for specific (root access) tasks to LineageOS, but "normal" SSH logins take me directly to the Devuan CLI.

    2 hours ago, matf said:

    tinkerers have found ways to use the proprietary Android compatibility on the community port

    I had heard of that, and it may work in some use cases. Overall, I think the Android compatibility layer has harmed SailfishOS more than help it. Regarding the web-browser, too many user requests have been answered by "well, just install Android Firefox". That cannot be the solution for what is (today) one of the most important applicatons of an operating system.

    • Like 1
×
×
  • Create New...

Important Information

Terms