claude0001
-
Content Count
790 -
Joined
-
Last visited
-
Days Won
120
Posts posted by claude0001
-
-
4 hours ago, PokeParadox said:
I've not got around to trying again, do you have a more recent set of steps I could follow? I don't seem to have much luck getting this set up.
I am ready to help, but I would first need to know what you are failing at ...
Please have a look at this post, and try to understand it, following the links I provided.
The first step is to prepare an SD-card with a partition containing the GNU/Linux distribution. This is best done from an existing (x86) Linux-PC using qemu as described in the first link of my post. As most modern Linux distros are based on systemd (which cannot run in an Android chroot), I suggest Devuan which uses traditional System-V init. It is possible to change the init system also in vanilla Debian, but that adds one more layer of complexity to the project you may want to avoid. 😉
Upon startup of LineageOS, that "Linux" partition of the SD-card is mounted via the Chroot script attached to said post of mine. Then, the script starts a few services within the Chroot environment, the most important ones being SSH and XRDP. On LineageOS, running the script can be automated by placing it into /data/local/userinit.d and installing the Run Userinit App from F-Droid. Note that the App -- as the Chroot script itself -- requires a rooted LineageOS.
With the SSH and XRDP servers running in the background, they can then be used for accessing the GNU/Linux environment, either remotely or by using suitable Android client-apps on the Pro1 itself.
Of course, you cannot just copy my Chroot script blindly. You should install your own system step-by-step, adjusting the script as required. Obviously, it is also good to first test the individual commands from an interactive (root) shell of LineageOS before trying to automate things using the script.
If we continue this discussion, it should probably be moved to another/a new thread, as this is explicitly about not using Termux now ...
-
3
-
-
12 hours ago, EskeRahn said:
If I don not remember wrong, the issue there is the margins, not that it does not react at all
You are right. But @Dyna Smart do not provide much details in their report: Replaced themselves or by FxTec? Source of the replacement screen? Installed OS?
My experience is that, in lack of more information, you never know what people understand by "not working at all", especially when they are at a certain level of frustration.
Hell: I myself have sometimes said my Pro1's camera was "not f**ing working at all!", although this is objectively far from true ... 😉
-
2
-
-
8 hours ago, DynaSmart said:
After replacing the cracked screen, the displa's touch function is not working at all (even after repeated re-booting).
Is there a solution to this bug?
In case you replaced yourself: most spare parts now seem to require a firmware update for the touch function to work correctly.
See this thread and the possible solutions discussed therein.
-
1
-
-
4 hours ago, raymo said:
I play a little whith termux, scripting inside Arch in order to automatize display and launching Xfce.
However I don't find solution launching XSDL apk from bash script yet,Termux is a nice project and has some interesting features. But as an in-app solution, I guess it will always be somewhat limited. That is why I decided to install everything from scratch by myself. Note that, in the beginning, I also knew nothing about chrooting Linux distros on phones: the Pro1 is my first Android device. Do not give up!
The reward for all the work and learning is that I have now a GNU/Linux distro running really in parallel to LineageOS, which allows me to use the Pro1 like an actual PC, while neither disturbing the Android environment nor depending on it in any way (except for the kernel, of course). I can SSH into my Pro1 for CLI access or file transfer. I can remote-desktop into it, which will spawn a fresh KDE desktop or reconnect to an existing session. I can start arbitrary GNU/Linux background processes via cron. All without relying on any supporting Android apps -- though it is of course possible and useful (thanks to the keyboard!) to have Android SSH or RDP clients ready for accessing the GNU/Linux environment on-device.
Yes, it was some work to get there. But it seemed like this was the only way the Pro1 could at last replace my beloved N900 ... 😉
-
3
-
-
Nice job! Always good to see I am not the only one using the Pro1 as an actual computer ... 😎
4 hours ago, raymo said:It also works with VNC but without sound
By using XRDP as a wrapper around VNC, you can forward sound from the VNC session to an RDP client (I recommend MS Remote Desktop 8 as it seems to work best with the Pro1's keyboard). This way you do not need a separate XServer on Android, and the Linux session can run in the background when disconnected. I gave an overview about such a setup in another thread. I do not use termux, but I guess it cannot install XRDP and the required PulseAudio drivers for you. You'll have to do that yourself from within your Arch system.
As I explained in this post, it is even possible to get rid of VNC altogether by using the (better performing) native X.org-backend of XRDP. However, that is even more complicated as it requires traditional shared-memory access from the Linux system.
Happy hacking.
-
1
-
1
-
-
1 hour ago, EskeRahn said:
Not saying that their timeframe will hold, but have a look at this
Oh, I did read that. As I did read all the other announcements since 2019.
I guess, for those who have followed FxTec's path for so long, there are only to possible outcomes: you become either a pessimist or a believer. 😉
-
2
-
-
1 hour ago, brunoais said:
In other words: Doable but I wouldn't put my bets on it
With all due respect: I think no one here ever got their phone within 3 months.
Even if mass production restarts in November, FxTec will be busy for months serving all the Pro1-X backers (and probably quite a few remaining Pro1 orders).
If you haven't pre-ordered a Pro1-X already, I do not think there is any hope to get it in the first half of 2022.
-
8 hours ago, jonyify said:
To eleminate clicking/popping sound: switch off NFC.
Confirmed on LOS 16.0: With NFC switched-off, no clicking when recording from the 3.5-mm-jack. Thanks for sharing!
-
2
-
-
1 hour ago, daniel.schaaaf said:
Will changes to 18.1 automatically integrate into the 17.1 code?
No, don't think so. Also the device-specific code has distinct branches for 16.0, 17.1, and 18.1.
That patch of @tdm is proposed against 18.1. So if it is accepted, it will be only in there.
Currently the driver in 18.1 is still (almost?) the same as in 16.0 and 17.1 so backporting the patch to your local 17.1 tree should be trivial. That may change in the future, as there are several proposals for improving the keyboard driver in 18.1.
I am loosely following that development, but almost certainly will not backport everything to 16.0, as I am in fact quite happy with the current low-level behaviour of my keyboard, even in complex use-cases (RDP) ...
-
1
-
1
-
-
5 hours ago, Apextech said:
If I had bought $700 USD in Bitcoin instead of this phone (which I still do not have) in Feb 2020, I would have over $2800 right now.
Try to be optimistic. Money is not everything. I paid my Pro1 (without the "X") also more than a year before I finally got it. Now that I have a real keyboard phone, I congratulate myself for the decision to preorder every day.
-
5
-
-
On 6/22/2021 at 8:15 PM, claude0001 said:
For the case anyone else still has interest in LineageOS 16.0, I've made them available here:
http://findus.zwergenschaenke.net/~puma/linux.html#lineagepro1
Build 20210922 is available. It includes the September 5 AOSP security fixes.
As of this release, the build includes a backported patch, originally made by @Slion for LOS 18.1, which allows one to use "Fn-Tab" and "Alt-Tab" equivalently for switching Apps (see this thread). I find that feature really useful when holding the Pro1 by the keyboard.
I have used that modified keyboard driver for weeks without issues. Still, be warned that this code has not been merged into any official LOS branch yet, and should thus be considered experimental.
Edit:
I think I should clarify: the driver included here corresponds to @Slion's "patchset 7" in 315155, i.e. the version before "modifier passthrough" was introduced. I follow the discussions around improving the keyboard driver in LOS 18.1, but will probably backport to 16.0 only what seems useful to me personally ...
-
1
-
2
-
-
1 hour ago, Rob. S. said:
Angelo is the newest addition to team F(x)tec, and 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.
I like those news in particular ... 😺
-
6
-
-
15 hours ago, tliebeck said:
I would strongly recommend the following:
- Place the /? key in the traditional location (replacing current \| key. (this puts in the traditional location on a PC/Mac keyboard)
- Replace the "Del" key with the \| key (this puts in the traditional location on a PC/Mac keyboard)
- Eliminate the right side "Up-Right" function key and replace it with "Del"
- Ensure that all yellow symbols can be rendered simply using the SHIFT key (I don't have my Pro1 yet, don't know if this is currently the case or not).
While I agree with most of your ideas, I think that ship has sailed. According to the last update from Fxtec, they should be in the protoyping phase by now. Even small changes to the hardware would likely introduce large delays at this point. As @VaZso pointed out, that's especially true for the Fn key which is wired differently than "normal" keys. So it is not only a matter of changing the printing on the caps.
That said, I would not worry too much. My experience is that typing on the phone and on the PC "feels" so different that it does not help to have identical layouts for the symbols (nor does it hurt to have some differences there).
I have a QWERTZ Pro1. And although that mimics the standard QWERTZ layout quite closely (I think as closely as possible without triple-labelling keys) this similarity to my PC keyboard did not help me much in learning to type efficiently. Most of the time, you thumb-type on the phone, so muscle-memory from the PC simply cannot help you find the right keys. And, even when using the phone on a desk, so that one can (in theory) use multliple fingers for typing, the gestures I am used to from the PC most often do not work, as the keys are simply too close together with respect to the natural span of my hands.
-
1
-
1
-
16 hours ago, Sean McCreary said:
I have verified that each key generates the glyph matching the printed keycap for QWERTZ variant Pro1 devices, as long as in 'Settings -> System -> Languages & Input -> Physical keyboard' *both* 'Advanced settings -> Physical layout' is set to QWERTZ *and* 'Builtin Keyboard -> Choose keyboard layout' is set to German. I will try to find a way to make it easier for users to set the correct configuration to make this less confusing.
Because this seems to be a configuration issue rather than a bug in the default keymap in the keyboard driver, I have abandoned CR#315195.
Exactly.
Out of interest, I had applied the proposed patch to my LOS 16 on my QWERTZ Pro1: The respective key immediately stopped working correctly. With @tdm's default keymap, things have always worked - given the correct configuration you describe.
That one has to configure things in two places is of course a little cumbersome, and many of us QWERTZies stumbled on that in the beginning. Streamlining the UI here would be nice, but also not strictly necessary, as for most users configuring this is a one-time action.
-
1
-
-
1 hour ago, Slion said:
What's your experience with call quality on LOS? So far I only had one phone call and the volume was totally ok, none of the extra loudness issues from stock. However as I tried to adjust the volume it did not seem to adjust by much I could hardly hear any difference. Not that it need adjusting though, it was just fine, just wanted to try it out.
Since I have never had stock, I cannot compare LOS to it regarding call quality. But I somehow remember @tdm saying the telephony bits were taken 1:1 from stock, so maybe there really should not be much of a difference ... All I can say is I'm happy with the few phone calls I make. Yes, sometimes I adjust the volume during a call, but no idea if the Pro1 is to "blame" in those cases, or whether it is my partner's phone.
That said, I am probably the wrong person to ask, really. I have accepted the fact that reliability and audio quality in telephony reached its peak around the time of the last mechanical-dial phones. Then we improved things further ... 😉
-
1
-
3
-
-
2 hours ago, Slion said:
It's not just cosmetical but I have no idea if you can just take it as it is to for earlier version. Though I would think so.
I was asking about the patch being "cosmetical" because in the commit message of the patch it says:
Quote[...] The current values seem to expect to be written as s32, this sadly won't happen and triggers a special case in the write handling of pm_qos_power_write: it expects char buffers to be encoded as base16 and decodes them. This means the current 44 is actually 0x44 -> 68 seen by the kernel. Luckily it seems like both accepted values for this node don't hit the threshold to enter C2, so it was never noticed in real usage and didn't effect the device C-States handling during hints.
(emphasis mine).
Actually the patch cannot be directly used in LOS 16.0 because more entries (related to the use of PowerHAL in later releases, I guess) have beeen added meanwhile. Anyhow, I backported the change from '44 -> 2c' to a test build of LOS 16, and that has been running normally on my Pro1 for two days now ... Question is, should there be any (net) effect of this change (e.g. regarding power consumption), or not? 🤔
2 hours ago, Slion said:However make sure you take the earlier similar change too as not having both will surely cause the lags we had on that one 18.1 release.
Yes, that one was clear to me. Thanks for the warning, though. 🙂
-
1
-
-
On 9/8/2021 at 12:01 AM, npjohnson said:
https://review.lineageos.org/c/LineageOS/android_device_fxtec_pro1/+/315360 - this was merged - we missed one conversion from 44 -> 2c, the value mismatch caused the powerhal to crash.
Issue is remediated.
Should this fix actually be backported to 17.1 and 16.0, or was it purely "cosmetical"?
-
2
-
-
22 minutes ago, VaZso said:
...and it also works well using a microphone connected to 3.5" Jack connector.
Had not tried that.
I confirm that recording from my 3.5-mm-jack headset does not have the background-filtering problem. However, recordings done that way have a low-volume (but clearly audible) "klicking" background (~2 Hz). Attached is a sample of that. Does not happen with the built-in mic (where it is probably suppressed by the filter). So, indeed it is better, but (for me) no ideal solution either.
-
1
-
-
The Pro1 seems to do quite aggressive background suppression when recording from the built-in ADCs, no matter what specific audio source is selected.
For normal voice recording, this actually works quite well for me. But I do believe this is what prevents you guys from recording music with the built-in mics: Depending on the tone and loudness of a particular part of the track, the filter takes the music for background noise and suppresses it. In fact, I think I can produce these artifacts even when I try to record myself singing (though normal speech works well). And, no, I will not upload that test sample. 😉
Now, one would expect one could bypass that problem by using the "unprocessed" audio input rather than "default" or "microphone". Sadly that does not seem to make much of a difference for me. If you want to experiment yourself: note that not all apps allow you to choose that input interface. One that does is the "Audio Recorder" from F-Droid (https://gitlab.com/axet/android-audio-recorder). Also OpenCamera has that option (but of course records videos, not audio-only).
From a USB microphone, I can record undistorted audio (also music) by grabbing directly from the ALSA interface. So I think nothing is broken on the kernel/ALSA level. Probably more a "feature" of the built-in audio hardware (or drivers), I guess.
-
3
-
1
-
-
6 minutes ago, claude0001 said:
True. But I regularly record GPX tracks of my hiking or biking tours with OSMAnd~, and they are always "noisy" and little "off" the road, so I believe it does not do such things.
Nope. I underestimated OSMAnd~ (again). 😄
One can indeed activate "Snap to Road", however that is active only during turn-by-turn navigation. Not when just recording or monitoring your position while you move around freely.
-
1
-
-
1 minute ago, EskeRahn said:
Note that some navigation apps tend to be smart, so if you move at some speed along a road it will snap you to the side of the road it expect you are.
(so this could muddle things further)True. But I regularly record GPX tracks of my hiking or biking tours with OSMAnd~, and they are always "noisy" and little "off" the road, so I believe it does not do such things.
-
1
-
-
Be remined that the accuracy reported by the phone is just an estimate.
Even under optimum conditions, the true position deviation can be significantly worse than the reported estimate, as e.g. this study found. In particular, the authors show that phones can, both, over- and underestimate their precision, and that models reporting better values may in fact have larger deviations in reality.
If surrounding structures (e.g. tall buildings) introduce systematic errors the receiver cannot sort out, these deviations can probably be much larger still.
My personal experience largely agrees with those findings. When observing my reported position in OSMAnd, I often see that it is obviously wrong by many meters (e.g. wrong side of the road), although the Pro1 believes it is already locked to 3-4 m. When I move around a little, it then suddenly corrects my position to a realistic one with no change in reported accuracy.
-
32 minutes ago, Slion said:
I wonder if you could just change the slot without reboot, from ADB?
You can, with fastboot.
fastboot --set-active=a-
1
-
2
-
-
15 minutes ago, daniel.schaaaf said:
Google and Lineage are going the wrong way, making things too "secure" and "fool proof". Root and SD-cards are a good example of the things the future won't hold.
As you know, I feel the same.
But in all fairness, let's say that Lineage is not actively going that way. It simply maintains compatibility with the respective Android release, which does make sense, right?
-
2
-
Protective Case Suggestions and Ideas
in General Discussion
Posted
This. That's also the most annoying issue I have with my flap case, which otherwise serves me well (see earlier in this thread). The strap is somehow always in the way, especially when taking pictures in landscape orientation.
When opening the flap by 360° it is possible to get the strap magnet to attach itself to the flap "in reverse", which gets both out of the way. But you obviously can't take pictures in that configuration.
What's more: in my case the magnet of the strap is exposed (i.e. not embedded in the leather, like in yours). Believe it or not, it has left scratches on the screen by now (Magneto: "Take that, Gorilla Glass 3 (tm)!"). Argh.