claude0001

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.

By "VNC Viewer" you mean this one? I'm pretty sure I tried that and I was unable to type most of the yellow level-3 symbols of the Pro1 keyboard. Do they work in your set-up? I also use TigerVNC as server. But as I have always been able to type all symbols when connecting from an external (non-Android) VNC client, I do not think the server is the problem anyway. In the end, it is also used as backend in my present XRDP solution, where all keys work. Thanks for sharing your project page. It contains a lot of interesting information. Though, it seems like you had to fix a lot of proble

I'm a little confused by your answer. 🤪 I was not asking whether you could use the button to launch the respective camera app (I really do not care about that function). I want to know whether you are able to use it in Gcam to actually take pictures. Goes like this: 1st-stage-press = focus-and-hold, 2nd-stage-press = shutter (without delay). I was also not talking about the quality of the optics. Of course, any (D)SLR is superior to a phone. I learned photography on an SLR (without the "D" 😎), so I should know. I was talking about the workflow of taking pictures by double-action-pres

Thanks for confirming this. As you seem to be using a Gcam-port, I dare ask once more: can you actually use the double-action shutter button? This may seem like a random detail to some. But for native SLR photographers, double-action focus/shutter is the natural way of taking pictures -- so the presence of that button on the Pro1 is quite important to us! OpenCamera makes perfectly good use of it, what about Gcam (ports)?

GCam has been recommended to me before. I do believe that it makes good pictures. Unfortunately, it does not run on a "pure" LineageOS (i.e. without Gapps et al.), as far as I know. So, whether Gcam is truly "better than other solutions" depends on personal priorities. My reasons for avoiding Gapps are more important to me than getting the max out of the camera. Philosophical questions aside, last time I read about Gcam ports, there was none that could make use of the physical double-action shutter button. That one is important to me. Has that situation changed? As I said: The out-of

Thanks for posting your experience. I think my use-case is quite similar to yours. I also use a self-made chroot with several user accounts. Also for me, setting this up has been a trial-and-error process (as this is my first Android phone). I posted my present set-up (including the chroot script) in another thread. Any suggestions for improvement are most welcome! In your post, one thing in particular caught my attention: May I ask what combination of VNC-server (in the chroot) and VNC-client (in Android) you are using? At least among the FOSS VNC viewers, I found none to fu

As far as I know, no solution exists to get accelerated OpenGL or video decoding as there is no DRM-API to make the GPU accessible from standard Linux programs. So games or videos in the Linux chroot will always fall back to software rendering (llvmpipe) and not be much fun to watch. Also the sparkle project you mention is just an implementation of XWayland (not Wayland) running on Android. I therefore doubt that it will give better performance or more functionality than the (actively maintained and probably more mature) XServer XSDL. That said, many people prefer to run their X-Serv

As I said, Gecko 52 ESR may be a big improvement over the engine in SFOS 3.3, but they are still failing to catch up. Gecko 52esr was released in 2017, since then we've had 60esr, 68esr and 78esr. 91esr will probably have been released (scheduled for July 2021) by the time Jolla adopts 60esr. The technical reason for this seemingly lost race is that SFOS's build environment (gcc, libc, Qt and all that) lags behind the average Linux distribution, so that recent versions of some programs (like Gecko) cannot be built (easily). Do not get me wrong -- I like the fact that SailfishOS

It was the first thing I tried -- because I knew that the browser situation in SFOS would be problematic. When you read about SFOS you quickly realise that this is a long-standing issue: Jolla seems to not have the resources to keep up with browser development (which is quite a task, I acknowledge). Things are made worse by the fact that their core community is on "official" devices, which allow to simply run Android Firefox via the compatibility layer. As a consequence, also the community have little interest in developing or porting a better native browser.

Thanks for the heads-up. I may give SFOS another try at some point. On my last test, I was driven away by the completely outdated stock browser-engine, as well as by the non-availabilty of more recent web-browsers in the reops. Now, the new version (3.4) ships with Gecko 52 according to the release notes. While this may be a significant improvement over the previous state, it is still ridiculously outdated considering that Internet access is THE most important feature in a smartphone (at least IMHO). Jolla need to get this lack of an up-to-date web browser fixed once and for all -- o

On my LineagOS 16: "android.lens.info.focusDistanceCalibration": "1" just like on yours. However, if I understand the docs correctly, this calibration affects only the object distance that is saved in the EXIF header of the pictures and has no influence on the optical functioning of the camera itself. As far as I know, auto-focus works by optimising the FFT of the actual picture on the sensor and does not rely on somehow "knowing" the true distance to the object. The distance that is saved in the picture metatdata is then derived from the (optimised) position of the lens with

Reading this I remember that I had the same phenomenon (black picture) when I tried SailfishOS. That was also at a moment when the camera was already supposed to be supported in SFOS. I did not try to understand this as I had then already decided not to stay on Sailfish anyway. However, as my camera always worked in Lineage (at least better than yours, apparently), there may be no relation to your focusing issues here.