Jump to content

claude0001

Members
  • Content Count

    746
  • Joined

  • Last visited

  • Days Won

    106

Everything posted by claude0001

  1. Overall I think this is a quite good analysis. That they managed to grow the (SD835) Pro1 from the ash of the Livermorium project almost seems like a miracle from today's perspective. The original Pro1 was indeed far from perfect. It had its QA issues, and also some design flaws. But overall, as you can tell from the numbers of Pro1s vs. Pro1-Xs offered on the aftermarket, those who have one tend to cling to their Pro1 to this date. It will remain the best (last?) keyboard slider for some time to come. Despite owning also a Pro1-X (admittedly through Expansis' grey-marketing 😳), I recentl
  2. Good point, but I would assume the SD835 QX1050 (aka. "Pre-Christmas-Pro1-X") to be compatible with the SD835 QX1000 ("original Pro1"). To my knowledge there are no differences besides larger built-in storage and larger RAM. Both shouldâ„¢ not prevent you from flashing an original Pro1 ROM. Have you tried that? Images made for the "post-downgrade" QX1050 with SD662 surely cannot work on a Pre-Christmas-Pro1-X (with SD835). Certainly true. But the different camera (two lenses vs. one lens) is the most apparent external difference between a "Pre-Christmas Pro1-X" (really an SD835 Pro1) fro
  3. Thanks for sharing. That keyboard looks quite interesting. I've bought this one some time ago, but the rubber keys are mushy, and the lack of a TAB key reduces its usefulness for terminal work quite a lot. Despite the similar "square" layout, which certainly requires some getting used to, yours looks much more functional Good luck with your slider project.
  4. There is a long thread about this: https://community.fxtec.com/topic/3427-sound-problems-with-no-response-from-fxtec-support-for-45-days-pre-christmas-device/?tab=comments#comment-59239 Unfortunately with no satisfactory solution. The Pro1 applies some aggressive filtering on the built-in mics that seemingly cannot be disabled. You get best results by using a USB microphone or by recording from the 3.5 mm jack. In the latter case, make sure to disable NFC during recording. It will otherwise introduce a low-amplitude, but clearly audible, "clicking" background.
  5. Does anyone have background information on this? Why did F(x)tec make this site private? Much valuable technical information on the Pro1 and Pro1-X is documented here, which is certainly relevant for aftermarket users, even though the Pro1/X are no longer produced. Think of the maemo.org forum, which is still active today, 15 years after the N900 was launched ... Could we have something like that?
  6. Despite my previously announcing the opposite, I did it again. Here are updated builds of good-old LineageOS 16.0 for the SD835 Pro1 (QX1000): https://findus.zwergenschaenke.net/~puma/linux.html#lineagepro1 The ROM dated "20240327" gives you all backported ASB fixes up to March 2024. As always, my build includes some local modifications specific to the Pro1, as documented in the patch tarball. These have not changed since last year. Credit goes to @Laska for getting me to fire up my old Pro1 again. This made me realise how much LOS 16 was better suited for my use-case compared t
  7. After using my Pro1-X for a few months, I confess that I am preparing to move back to the (SD835-)Pro1. Things initially seemed to work out after I had fixed my GSM/LTE connection issues by replacing the antenna board of my Pro1-X. However, in day-to-day use, the device simply couldn't compare to my Pro1. Some of the things that eventually turned me down: This is actually more a problem of Android 9 vs, Android 13, but it still bugs me a lot: Setting up my Linux-in-a-Chroot setup on the Pro1-X was possible, but turned out to be much less functional compared to the original Pro1 (w
  8. @tdm's driver unfortunately does not come with much documentation outside the source code itself. @Sean McCreary has summarized things in a way I could not best: https://community.fxtec.com/topic/3347-how-to-customize-the-keyboard-layout-on-lineageos-181/?do=findComment&comment=57526 In short: The first column of the keymap is a decimal "key-number" specific to @tdm's driver. The next two columns are the hexadecimal Linux (not Android!) input codes to be generated by that key, either when pressed alone (second column), or together with the "Fn" (yellow arrow) modifier (third
  9. Hi @Laska, The keyboard driver for the Pro1 has been completely rewritten by @tdm when he did the original port of LineageOS. The keymap file in LOS 16 is located in /sys/bus/i2c/drivers/aw9523b/6-0058/keymap. However, any changes to that file are not persistent across reboots. If you have root, the easiest way to make changes persistent is the following: Install the app Run Userinit from F-Droid. Execute Run-Userinit once and grant it root privilege. Next, place your modified keymap e.g. in /data/system/keyboard/keymap (you may have to create the "keyboard" folder
  10. OK, I ventured a down that rabbit hole somewhat, and it turns out you are, in a sense, both right. In fact, phones had, and still have, a real time clock (RTC) that is able to keep time even with the device powered-off. However, as I learned from here and here, the RTC on Qualcomm devices is read-only. Upon the very first power-on, it initializes itself at 1st January 1970, 00:00:00 UTC ("Unix epoch"), and then just counts from there onwards through the lifetime of the device. Indeed on my (rooted) Pro1, the RTC clock returns rostkatze1:~ # hwclock -r 1973-09-11 08:31:30.407
  11. Hi Laska, Indeed, what you observe is expected behaviour if "System > Date & time > Automatic date & time" is disabled and/or if automatic syncing of the clock is not possible because of lack of network coverage or because no SIM is inserted in the device. I do not know if this behaviour is specific to my ROMs or if it is a general thing with Android 9/Lineage 16 and the realtime clock. I did not (consciously) change anything in the code with respect to this. A quick internet search suggests it is quite widespread behaviour for Android devices to just assume
  12. Because this thread received a like recently: I have moved to a Pro1-X several months ago and have not made any new builds of LineageOS 16.0 for the (SD835) Pro1 since. Even though I liked LOS 16.0 more than recent versions of Android, there is no realistic going back for me. If you really want an updated LOS 16 for your Pro1, p.n. me. I'll then see what I can do ...
  13. @EskeRahn , I think that other thread was much about running desktop-Linux-like systems in chroot environments or similar container techniques that all use the Android Linux kernel. This one is specifically about mainlining progress. I do not think we have that already. Edit: Ok see what you mean. This started to mix in the latest posts ...
  14. No, I think you got me wrong. No offence but, like many, you do not seem to understand what "Linux" really is. Do not worry, you are not alone in this. Especially people with many years of experience in running Linux on x86/64 servers or workstations often make wrong assumptions when it comes to embedded systems, like phones. Android does use a real Linux kernel, and thus is a true Linux system. You can grab its kernel source from kernel.org, configure it to you liking and create your own custom ROMs based on it. The only limitation is that you practically can only run the single major ke
  15. Droidian, like all functional alternative OS's for the Pro1X (Ubuntu, Sailfish, Droidian), works by specifically not using the "mainline" (i.e. upstream) Linux kernel. Under the hood, they all run a minimal version of Android 11, including its original (downstream) kernel version and closed-source driver binaries. That hidden Android OS is then interfaced from the GNU userspace via middleware layers like Halium and libhybris. While this technically works well, it also means that critical bugs in the driver blobs are present in these OS's just as if you were running the original Android 11 OS t
  16. Hi @Casey. Thanks for your thoughts on this problem. Indeed, as I tried to make clear above, I cannot really exclude I did break the antenna contacts myself. One I certainly did. No, I did not track this down because I heard something rattling inside the phone. I had previously opened the Pro1X's main body several times in the context of the battery depletion bug I had experienced, and because of the right-speaker-noise-at-full-charge issue. At that time, I did not pay much attention to the state of the contact springs (I did not even know what their purpose was). Though I do not rem
  17. Let's not jump to conclusions prematurely. I had opened the Pro1-X multiple times, so I cannot exclude that I broke these contacts off myself. One I definitely did, as noted above. That's also the reason why I did not try to make a warranty claim out of this. Then again, two of the connectors seem to really have disappeared, so maybe they were missing from the start indeed. For sure the Pro1-X had its connection issues since the first time I put a SIM in it. Lets see if others affected by the issue find the courage to open their devices, and discover similar problems. Indeed,
  18. @MonCon I've experienced a "battery depletion event" once with the Prawn-X. As documented here: The battery voltage, as measured with an external voltmeter, was "0.000 V" indeed. So booting into whatever runlevel of Android would not have been physically possible any more. In that situation, the only way forward is to charge the battery using some external power supply, as documented in my post above. I guess this is also what F(x)tec are doing if you send in your device for repair.
  19. So, it appears that I was able to repair my Pro1-X's radios. Previously, telephony and mobile data wouldn't work for me, as documented earlier in this thread. WiFi, Bluetooth and GPS had always worked perfectly. It turned out that my Pro1X was missing most of its "antenna" connector springs. My main antenna (aka. USB) board was missing two of its three connectors, and the last one broke off while I was diagnosing the problem. See picture attached. It appears these things are really fragile. Also my "diversity" antenna board was missing one connector, which I found rattling in a
  20. Contrary to popular belief, that setting cannot protect you from the battery depletion bug. As @Sean McCreary clarified in some other thread, Android devices are not really "off" during "off-mode-charging". The charging screen is just a different runlevel of the operating system. The bottom line is that the Pro1X's Linux kernel has to be up and running in order to actively switch the power source from the battery to the USB charger. That won't happen "on its own". So also with off-mode-charging enabled, there has to be enough remaining battery juice for an initial boot of the OS, oth
  21. ... as to Reportedly (some?) issues related to WiFi were fixed via OTA. Is your device up to date? (I do not have a Titan, but am seriously considering it as my Pro1's keyboard is getting worse and worse ... 😥 )
  22. It seems like many Titan power users install the Blackberry Keyboard app to improve behaviour in that respect. Have you tried that by any chance? As written above, I'd be most interested in a way to fluently enter all those symbols for coding and terminal work, i.e. things like | > { } [ ] ...
  23. @Hook, he needs the sources, apparently including the exact building configuration. ROMs contain only the resulting binaries in executable form. @pAn : You probably have good reasons for what you are doing. But out of interest: If you kernel project works well with LineageOS, why don't you just use that?
  24. The "stock" kernel sources (you didn't mention if you are on Pro1 or Pro1-X) are available. That's what the LineageOS trees are using. Of course @EskeRahn is right that those do not contain the source code of all the (mission-critical) vendor blobs.
  25. The Pro1X's USB port does not support GPU-out via alt-mode. Therefore things like UBTouch congvergence mode will never work, contrary to what was promised. As far as I understand, the solution that was demonstrated with that "USB to HDMI" cable relies on screengrabing and -casting over a network protocol and thus works independently of the GPU on any recent Android device. The screengrabbing part is probably the reason for the extensive permission requirements. It's also the reason why things like Netflix or Prime cannot be displayed using such tehniques (as they have DRM mechanisms
×
×
  • Create New...

Important Information

Terms