claude0001

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.

That is awkward and I understand your frustration. I find it quite surprising that the same App behaves differently in Stock Android 9 and Lineage as I thought that the bits touching metal (Linux kernel and hardware drivers) are identical in the two OS'es. Does anyone understand how the secondary lens of the Pro1 operates? I know that it is meant to provide depth information to allow things like "fake bokeh", but I do not know at which level (hardware, driver, application) such effects are applied. If the depth field information is processed on the level of the OS, maybe something co