claude0001

I can see nothing bad in that principle. 🙂 That said, as far as I know (from reading alone) the external display works in tandem with PlanetComputer's Android 9 apps. I wonder if it does anything when the phone is operated with the Linux OS.

Well, that's my point: Being able to use phone apps and desktop apps in parallel. A priori, there is no technical disadvantage of both environments running at the same time on the same (Android) Linux kernel -- apart from somewhat increased RAM usage which is not really a problem on devices like the Pro1(X) that simply have enough of that. It is true that Chroot or LXC solutions like mine (on Lineage) or @matf's (on Sailfish) do not have direct hardware access to a lot of features (telephony, GPU, GPS, ...). However, this is not a technical problem: it is a consequence of the kernel

Some might have definitions of "everything you need" that differ from yours. 🙂 I'm coming from an N900. When you are used to a full Unix computing environment, there is really no way to fulfil all your needs with Android and Android Apps alone. Example? Using my Debian chroot, I could compile and install MAD/X [cern.ch] on my Pro1: So I am now, literally, able to design f***ing particle accelerators using the Pro1. Now go and try that with Android 😎 . P.S.: ... OK, OK, this port was just a fun project. I'll probably never actually design an accelerator with the Pro1 (

That's totally not what I, and many others, have in mind. We want to run a conventional desktop Linux environment (with GNU userland et al. ) in parallel to the phone OS. Please have a look at @matf's demonstration I linked above to get the idea. We also want to run our desktop environment on-the-go (i.e. on the device's screen). I can imagine very few practical use-cases for these so called "convergence" modes (as in Android 10 and UbuntuTouch): When I am close to a big screen, there is likely already a real PC attached to it anyway, why should I then bother to use my phone as such?

If it is the same keyboard than on the Cosmo and Gemini, it seems to be as "mechanical" as you can get. The keys are individually supported and seem to have good travel range. This also comes with some disadvantages, though, as there have been reports of "pocket dirt" going under the key caps and being difficult to remove 😄. It is true that since mid-2020, they seem to be making good progress with their Linux distribution for the Cosmo. However, dual-boot is really not something I would like to have on my device. For the Cosmo this may be acceptable, as it is a quite awkward phone anyway.

I also think that the Pro1's opening mechanism is much more robust. However, let's be nice among keyboard-lovers and recognise that the AstroSlide will have the much better keyboard -- probably more or less identical to the one its precursors had. From all that I have read, it seems to be as close as you can get to a "real" 10-finger keyboard in a PDA. In all honesty, I find that the Pro1 is some "in-between" solution that seeks to be compatible with, both, thumb-typing as well as multi-finger operation (when the phone sits on a table). As a result, it fulfils both roles pretty badly

Thanks to @Linkandzelda's support, I found the solution to my write-access problem as documented in this thread. In short: In Android (and LineageOS) write access to partitions of the internal storage (not including SD cards, apparently) is protected by a kernel-key. While a chroot environment normally preserves those keys, they are explicitly dropped (for safety reasons) in many Linux distributions when users log on remotely (e.g. via SSH). @Linkandzelda have posted a very informative how-to [external] on their own Linux-Chroot solution that (among others) discusses that problem, which -

That was it! Thanks @Linkandzelda! I mostly use my chroot via SSH. Even on-device, I use termbot to access the Debian CLI. As in your Arch, also on Debian the PAM config prevents SSH logins to inherit the keys by default. Instead of patching the PAM scripts, I for now simply set "UsePAM no" in /etc/sshd_config. Up to now I see no disadavantage in doing so ... In fact, in my X11 session, access to the /data/media/0 of Android had always worked -- as you write in your how-to, the Xsession inherits the keys automatically. I had simply never tried outside of an SSH session ... 🙂

I tried that of course. I'm pretty sure xev was not showing any signal for some key combinations. I'll give it another try at some point. I am actually now pretty happy with XRDP as that way the same client app can also transport sound to the Android side. 🙂 As for the mount: I was now pretty sure that it is Android security that prevents writing to the filesystems. This may be a side effect of not using a "helper app" like Linux Deploy (that is registered in Android to have write access). I'll read the respective section of your notes and come back if I have questions. Thanks.

@EskeRahn F-Droid just updated my OpenCamera. In the release notes it says: "HDR fixes for specific scenes". Maybe time to re-test.

This. I am a FOSS enthusiast. But unlike many, I do not think that the security advantage of FOSS stems primarily from technical superiority. The main problem with non-free as-in-'freedom' platforms is that -- sooner-or-later -- they end up being also non-free as-in-'beer'. Then, some class of users, who are more willing to download any SPOS¹ off the Internet than to pay their 5 bucks for an official copy, reach a critical mass. The rest is history. 🙂 ¹ steaming pile of sh*t

Reviving an (almost) zombie thread, because I stumbled upon this: It seems like few know that Collabora, one of the major developers of LibreOffice (and many more FOSS projects), make a free (like in 'freedom') Android (and iOS) version of LibreOffice, rebranding it to "CollaboraOffice". The apps are officially recommended on libreoffice.org. They regularly update the app to keep it in-sync with the stable LibreOffice code base. And while it is of course difficult to compare to the desktop version in terms of usability, the software does a quite good job at viewing and editing (!)

🤦‍♂️ ... that was too obvious. I did not know the Pro1 had already an image listed there. Looks promising, indeed. Thanks for the update. Still, I'll probably wait for 2021 (and more positive reviews) before I attempt the jump.

Thanks @Raksura, for answering your own question and posting you experience here. I am also very interested in UbuntuTouch. But as I rely on my Pro1 as my only phone, I cannot afford to experiment too much with it. I would well be ready to give UT a chance for a few weeks, if I could be sure that basic stuff like telephony and GPS are working at least. Apparently this is not the case yet, so thanks for the warning. Is there any place where one can follow UT development for the Pro1, specifically (a list of open issues/bugs related to precisely that device)? What is the presently

Sounds plausible. Of course in a laptop, some internal devices are permanently present on the bus and cannot be easily disconnected. That said, I tried every port available. Both of my Thinkpads have docking stations and it does not work even with the ports on the dock, although they have their own controllers as far as I know. 🤔 Whatever, with the Raspi it works 100% reliably up to now -- good enough for me. I do not have to understand everything.

Well, no Windows here. 😎 All my PCs are running Linux (as does the RPi3, obviously). I believe it's the USB hardware that makes the difference, not the OS.

This. That USB connectivity on the loader level is so picky about the partner device is a huge pita - it is however no problem that seems to be limited to the Pro1. For the records: I found that the only device I can use to reliably flash my Pro1 is my Raspberry Pi3. Both of my oh-so-sophisticated Thinkpads (one with USB2, one with USB3) either do not detect the Pro1 at all or run into random errors during data transfer. Considering how cheap the Pi3's are, I am thinking about getting a spare one just for the purpose of interfacing with the Pro1. 😄 Edit: @MickH : Good luck with

Most remote desktop solutions (on Android) can emulate right click by two-finger tapping the screen. Some can even do middle click, though my MS RD8 can´t. Security should not be an issue as you can limit access to localhost only in TigerVNC or XRDP. If needed, one can then still access the device remotely via SSH tunneling. Performance is worse than in your solution as the remoting layer adds extra overhead. Mounting my "home" in Android (i.e. /storage/emulated/0) is precisely what is working only sort-of in my chroot. Effectively, I can only read data from there, but not write there, ev

Yes, I believe libhybris-based systems do not contain Mesa at all (but I might be wrong). I think via libhybris programs can directly use the Android rendering libraries via EGL (not OpenGL though). Note that libhybris is for much more than just graphics. I totally agree, that by using libhybris as a workaround one can build a GNU/Linux distribution (the "GNU" is actually the major difference) ontop of an Android kernel (with closed-source drivers). SFOS and UT demonstrate that this is possible. All I say is: this does not help people (like me and @matf) who want to (additionally) ru

As far as I understand, EGL is used for sharing the pixmaps between drivers, client-apps, and Wayland. It has nothing to do with rendering itself. Which is done either by the clients themselves or by some libraries they load. In the example of your picture: A (3D) "game engine" renders its content using Mesa3D via OpenGL function calls. Mesa makes bitmaps and shares them with Wayland to display. Now the problem with closed-source Android hardware is that "DRM" and "libDRM" are missing. Hence Mesa3D has to fall back to software rendering.

That discussion you quote (if I understand it right) is about the hardware-acceleration in the compositor itself, not about client applications. I believe you have a misconception about what Wayland does and doesn't. Wayland does not provide a rendering API, i.e. it does not render stuff "on behalf" of its clients. All it does is paint ready-made bitmaps to the screen that the applications provide it with. How the apps do their rendering is completely up to them. As a consequence, also making use (or not) of hardware-acceleration during rendering depends entirely on the client apps.

I was talking specifically about "desktop" Linux distributions (as is @matf in his original post). In trying to be optimistic, I believe you actually illustrate quite well why Android hardware support on desktop Linux will not happen anytime soon. 🙂 Yes, it is possible to use Wayland (and, still, Mir) with libhybris to provide a hardware acclerated display and window manager on an Android device. However, that is not enough. At the end of the day, Wayland just paints ("composes") windows on the screen. Having a hardware-accelerated window compositor does not magically enable hardwar

I had seen this post already quite some time ago, but did not have time to comment up to now (or was too lazy ...). Thanks for sharing this. Your set-up looks quite impressive. I use my Pro1 in a similar way, but -- for now -- using LineageOS as the basis (see this post). I do have a few questions, that you may or may not be able to answer: * As long as all alternative OS'es (Lineage, Sailfish, UbuntuTouch, ...) use the same original Linux kernel from stock Android 9 and its (closed-source) drivers, we will never get things like hardware-accelerated graphics in a "desktop" Linux inst

In case you are running a real chroot (not proot) or require root access for some other reason, beware that AddonSU is not available anymore starting from LOS 17.1. So in case you are presently using that (like me) you will have to switch to Magisk -- which seems to work ok but adds a new level of complexity to root management. Also, it needs to be re-installed at every OTA update as far as I know, which was not necessary for AddonSU on LOS 16. I did not update my set-up yet for this reason alone.

All server startup scripts in Debian are meant for systemd. They are not expected to work in a chroot (where systemd is not around). Just start /usr/sbin/xrdp-sesman and /usr/sbin/xrdp manually, as I do in the final lines of my chroot startup script (attached to the post). For initial debugging, it is quite useful to start them with the flag --nodaemon from an interactive session, this way you can see what actually happens as you try to connect.