claude0001
-
Content Count
790 -
Joined
-
Last visited
-
Days Won
120
Posts posted by claude0001
-
-
51 minutes ago, Laska said:
But I don't understand content of this file -this is not lookng like .kl type file and I don't know how to remap keyboard with those codes
@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:
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 column).
-
2
-
-
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 first).
- Put an executable script named e.g. 01_install_keymap_mod.sh into /data/local/userinit.d/, with the following content:
#!/system/bin/sh # cp /data/system/keyboard/keymap /sys/bus/i2c/drivers/aw9523b/6-0058/Now Run-Userinit should take care of overwriting the default keymap with your modified one at every boot.
Note that @tdm had actually intended keyboard modding to be more user-friendly. On the "keyboard" panel in Settings, you'll find an option named "Custom keymap" that should have automated copying of the keymap, as done above by our script.
Unfortunately, the function got broken somewhere along the way after LOS 16 had become official, and was finally fixed only in LOS 18.1. As further changes to keyboard handling had already been introduced at that point, backporting the patch to LOS16 seemed no longer trivial and I did not try it. If possible, get root for your LOS16 (I miss addonsu ...) and use the above boot-script method for automating this.
-
5
-
10 hours ago, EskeRahn said:
There are no internal clock in any smart phone I know of, so it needs to fetch the time from some external source.
5 hours ago, MonCon said:Fascinating, I always presumed mobile phones had either a little lithium battery or a big capacitor holding up the clock while powered down or rebooting or such.
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.407173+01:003 years and 9 months ago coincides pretty well with the date in mid-2020 when I received my Pro1. Note that the (volatile) system clock is independent of the RTC and does show the correct time, as set automatically on boot via the "Automatic date & time" option:
rostkatze1:~ # date Sat 16 Mar 11:54:40 CET 2024However, re-setting the RTC based to the time of the system clock using the hwclock command (as would work on any regular Linux PC) fails because the RTC device does not accept the input:
rostkatze1:~ # hwclock --systohc hwclock: ioctl(RTC_SET_TIME) to /dev/rtc0 to set the time failed: Invalid argumentAs explained in that Qualcomm forum thread above, the only way Android can make use of a QCom RTC to keep precise time across reboots (or longer power-downs) is to keep record of the offset between the system clock and the RTC. At the next powering-on, the system time can then be reconstructed from that information and the number of seconds spent in power-off state, as measured by the RTC. Seemingly, many vendors or devs simply do not care about implementing that workaround ...
Supposedly, the read-only nature of the Qualcomm RTC is there to harden the systems against attacks relying on faking an earlier (absolute) lifetime of the device.
I learned something today. Otherwise nothing to see here ... 😄
-
4
-
-
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 they'll always be able to sync time via network upon boot, and hence to not care about setting the RTC properly. I wouldn't be surprised if the Pro1 just did the same ...
With "automatic date & time" enabled, this has always been a non-issue for me. I think NTP syncing should also work with no SIM in the device if you are in reach of a trusted WiFi.
-
2
-
-
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 ...
-
4
-
-
@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 ...
-
12 hours ago, denden said:
I would love to be able to run plain old linux on it (I am seeing that my understanding was correct, that "mainline" linux is just that).
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 kernel version (e.g. 4.19.xxx) your phone was shipped with. The profane reason for this is that all those drivers the phone's functions rely on are typically available only in binary form (as *.ko "kernel objects") from the vendor, and will only run together with the one kernel version they were compiled with. There is the purpose of "mainlining": reverse-engineer the driver code so it can be included in the living Linux source tree. Unfortunately that is a tedious process. But if we had the source code of all drivers, Android would be a completely open Linux system.
When you say you want to run "plain old linux", what you really mean is you want to run a "GNU system with a Linux kernel". Before the advent of embedded systems, the "Linux" vs. "GNU/Linux" thing was often seen as a purely philosophical debate. If you are willing to learn, Android can teach you a lot in this respect: While running on the Linux kernel, Android is not a GNU/Linux operating system. This is possible because the difference between a "Linux" and "GNU/Linux" system does not lie in the kernel, but in the C-library! The latter is as important a component of any UNIX system than the kernel itself, and the designers of Android decided not to rely on the GNU C library (glibc) -- as used in all those PC/server Linux distros you are used to -- but to develop their own C-library: bionic. Almost all of those "Android is not real Linux" arguments collapse to nothingness once you understand that technical background.
Now, you and many others (myself included) have been looking for ways how to run a GNU/Linux-like environment on their Bionic/Linux phones. That is where all those "Linux-like" alternative OSes (UB Touch, Sailfish, Droidian) come from. All those systems implement a middleware layer (libhybris) in-between their GNU userspace and the vendor-supplied Bionic/Linux base system. That middleware translates system calls from glibc to bionic so you can run all that open-source software we know and love. In my personal view, those systems do qualify as true GNU/Linux systems, even if relying on a vendor-supplied Bionic/Linux system (Android) underneath. My above comments about sustainability of course still hold.
-
2
-
5
-
-
4 hours ago, denden said:
how does this differ from Droidian?
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 that came with the phone.
Using outdated binary driver blobs in more recent kernel versions is not and will never be possible. That's due to first principles of Linux's architecture. Mainlining is thus the only sustainable way for a hardware to be supported in the long run. Kudos to @Danct12 for their effort.
-
2
-
-
15 hours ago, Casey said:
It's hard to say whether these antenna connectors were broken when shipped, or due to disassembly on your part. Have you've heard the antenna rattle inside the phone when you first received it? Would that be the reason why you took apart your device to check?
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 remember breaking/loosing any, I cannot say for sure.
It was only after reading your above-cited post (where you explicitly mentioned the fragility of the contacts)
I figured this could be the reason for my long-standing mobile network problems.
I wonder how many folks affected by radio problems have actually previously opened their phones, unaware of how careful one needs to proceed, and that you should never insert your prying tool into the short sides of the phone ... The Pro1/X were much advertised as being easily maintainable. They aren't really in this respect ...
But do not get me wrong: I am not complaining. Thanks for providing me with those spare parts. For now, the Pro1X's modem seems to perform similarly to my >3-year-old Pro1's, at least in my living region. For the first time, and despite the former's remaining issues, I am actually now looking into configuring it to be a successor to the latter ...
-
1
-
2
-
-
2 hours ago, EskeRahn said:
At the least that could explain why some sees this issue and some not, as it thus seems to be related to specimens, and errors in assembly (and QC).
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.
12 hours ago, foxfreejack said:I'm not sure why there's glue for those contacts on the board, but they should be soldered as well.
To me this means soldering wasn't great (or non existent!) to begin with and will induce all sorts of noise for cellular and wifi signal inside the phone to begin with.
Indeed, the contact springs are glued to the board. I cannot see any solder on my broken one.
I am no expert on RF signals. But I can imagine that, at the high frequencies involved, the capacitive reactance of the contact will always be very small, even if the ohmic resistance is non-zero. After all, the actual antenna is the metal body of the phone. And that is also not soldered to the circuitry, but just pressure-contacted by those springs ...
-
1
-
3
-
-
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.
-
1
-
2
-
-
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 different place of the device.
So, if you have mobile connectivity issues, carefully open your Pro1X and check whether your "main" and "diversity" antenna boards look exactly like the pictures posted by @Casey here:
Long story short, I ordered both, a "main" and a "diversity" antenna board from F(x)tec. The USB/main antenna board is very easy to replace. Replacement of the diversity module requires soldering work that scared me off. So I rather re-glued the broken connector spring in place and keep the spare part ready for future repairs.
In result, the Pro1X now performs similarly to my Pro1 when it comes to mobile network connectivity.
-
2
-
10
-
-
17 hours ago, MonCon said:
Doesn't the 'fastboot oem off-mode-charge enable' or 'fastboot oem off-mode-charge 1' discussed in this thread: [...] alleviate the flat battery problem, (at least on stock android at the moment), or can you still end up in a chicken and egg situation where you can't charge to turn the phone on, and you can't turn the phone on to charge.
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, otherwise the device is bricked.
-
1
-
2
-
-
... as to
2 hours ago, EskeRahn said:The worst (for me) is the unstable WiFi.
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 ... 😥 )
-
2 hours ago, EskeRahn said:
The second is that it is virtually impossible to get to things not printed on the keyboard
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 | > { } [ ] ...
-
1
-
-
@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?
-
1
-
-
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.
-
1
-
-
18 hours ago, Hook said:
But the statement you quote is not wrong. It is simply that only one USB-c to HDMI cable works and requires an app and only mirrors.
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 in place to prevent screengrabbing), unlike with true HDMI-out.
-
2 hours ago, xelo said:
I think it's time to close the door and move on.
Agree 100%. This party's over.
-
I have uploaded a new build of LineageOS 16.0 for Pro1 (SD835) at:
https://findus.zwergenschaenke.net/~puma/linux.html#lineagepro1
It gives you ASB fixes backported to Android 9 up to patchlevel "5 August 2023". There are no other changes with respect to the June update above.
I will continue to make new builds of LOS 16 as long as I use my Pro1 or until Markus stops backporting the ASBs, whatever comes first. However, as the Pro1/X community -- and by extension this forum -- seems to be dying, I'm not sure I will keep updating this thread much longer. If you are using my builds, check my website above for ROM updates.
-
1
-
2
-
-
3 hours ago, cdoublejj said:
So basically for those that have them already it is what is it's just a matter of updating lineage os and keeping them going.
Unfortunately, there are flaws with the devices that cannot be fixed by the LineageOS folks.
The most prominent is the the mobile connectivity issue, preventing many devices to effectively work as mobile phones. Then there is the dreaded "battery depletion" bug which results in a bricked device for Average Joe. There are more - less disabling - issues that will never be fixed with F(x)tec being effectively broke, like the "right loudspeaker fail at high battery charge bug" and others...
I had genuinely believed the Pro1-X (QX1050) could be a viable successor to my Pro1 (QX1000). It cannot.
-
2
-
-
Nope. The Pro1-X project is dead in the water, with most ordered (and paid) devices not even delivered to customers yet.
Reportedly, the phones have actually been manufactured. But for almost a year, F(x)tec have been unable to pay for continued shipping. They seemingly are also unable to refund disappointed customers cancelling their orders. At least one of their other products (linxdot) seems to be haunted by similar troubles, suggesting the company is nearly broke.
I actually expect them to announce end-of-business in one of the next IGG updates.
-
1
-
-
2 hours ago, david said:
I didn't realize T-mobile was in other countries.
The "T" in "T-Mobile" actually refers to the German company "Deutsche Telekom AG". The various T-Mobiles around the world were initially independent operators that have been purchased by Telekom and incorporated into their brand.
Of course, inspite of the similar name, the radio frequencies in use are different for all of those networks, as they are governed by the different national authorities.
-
3
-
-
Battery depletion bug.
Send your phone to Fxtec (good luck with that) or fast forward to here:
-
3
-
Experience so far with Pro1X
in General Discussion
Posted · Edited by claude0001
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:
End of story: I am currently re-fitting my (SD-835-)Pro1 for some more years of usage, and have just purchased another pre-owned Pro1 as a replacement device. Watch out for some more Lineage-16.0 ROMs for QX1000...