Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by claude0001

  1. 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
  2. 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
  3. 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)?
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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
  11. 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.
  12. 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
  13. Yes, I see that too. As you mentioned above, "infinity" is not actually infinity. Objects at "infinite" distance are imaged sharply with the focus set to "somewhat-less-than-infinity", e.g "1000 m". I agree that this renders the "Focus-locked-to-infinity" mode of OpenCamera useless, I had never tried that mode before. However, this does not prevent me from putting distant objects into focus. That is perfectly possible for me, both manually (using the focus slider) or using auto-focus. I never used stock Android 9, so I do not know how my lens would behave then. Did you try switching
  14. The camera of the Pro1 is not very good. To make things worse, the driver seems to be a mess. However, I am slowly getting it under control (still using Lineage 16) after installing OpenCamera instead of the stock LineageOS camera app and switching it to Camera2-API. OpenCamera exposes the "Scene Modes" supported by the camera driver. For me, the default setting "Auto" does not behave well in many situations: it sometimes defocuses the picture at the very moment I press the shutter button, although the picture is sharp in the viewer before. Seemingly, the camera driver tries to do so
  15. I did achieve my "desktop experience" using a Debian Chroot on top of a rooted LineageOS 16.0 (the same result could probably be obtained using Stock Android 9, if rooted). I installed a customised Debian on a dedicated partition of my SD-card, basically following the receipes found here: https://bogeskov.dk/DebianAndroid.html https://wiki.debian.org/ChrootOnAndroid https://unix.stackexchange.com/questions/321491/android-chroot-networking-issues Using Run Userinit from F-Droid, I mount the Chroot at /data/DEBIAN and start its SSH server on boot of the Pro1 (I attach my Chroot sc
  16. The announcement of the Pro1-X suggests that UbuntuTouch could very well become a first-class citizen on Pro1/Pro1-X. So I assume that some development effort must have been going on on the side of the Ubuntu port. I wonder why there are no news on this. Is anyone on this forum following UBPorts development? Are there other sources of information?
  17. Firefox here. I use that on all my PCs too. Mainly because it reminds me of the good old times when it was the only well-supported open-source browser. 😎 With that being said, can anyone actually use this site (the forum) via Firefox on the Pro1? I can't. In the standard "mobile" view, the site is slow like s.... and the "Quote" buttons below the posts do not work. When I switch to "Desktop site", the page loads faster, but the "Quote" function is not displayed at all! I presently have Daylight 82.1.1. Anyone with similar problems? Needless to say, Firefox works correctly with o
  18. In my opinion LineageOS 16 was a very important OS for the Pro1 that brought the best out of the device at a moment when stock couldn't (yet) . Although not a developer, I can well imagine it also broke the ground for all future releases of Lineage on the Pro1. So, I guess this is an appropriate moment to thank @tdm for all the hard work!
  19. OK, thanks for the information. That 16.0 will not get any security updates from upstream is a pity though. From what I read, the changes related to su would render the upgrade of my set-up to 17.1 non-trivial at best. So I'll have to stay with 16.0 for now, at least until I learned how to efficiently use magisk together with LOS on the Pro1 ...
  20. Bumping my question from above as the silence about this worries me a little bit. After all, LineageOS 16 is the very topic of this thread. I was hoping to keep LOS 16 on my device for a while, not expecting it to be abandoned so quickly. I worry that 17.1 will not work as a drop-in replacement for me due to the absence of AddonSU, which was a nicely integrated and low-profile root-management solution. I require permanent root access for several things (SSH server, Debian Chroot, cross-system file management), but I obviously do not want random apps to be able to su all the time.
  21. Well, on October 31 the target "pro1 userdebug lineage-17.1" was added to the build system while "pro1 userdebug lineage-16.0" was removed. That does not seem like a malfunction, it was done on purpose. See the diff here: https://review.lineageos.org/c/LineageOS/hudson/+/290451/ Until the respective target is re-added, the build system will not compile 16.0 for our device anymore. Independently of that, the build(s?) for 17.1 seem(s?) to have failed last Monday, as a patch to fix a build error was introduced on Monday evening: https://review.lineageos.org/c/LineageOS/androi
  22. Wondering why no new OTA updates had been offered for a while, I checked https://www.lineageoslog.com/16.0/pro1 There it says: "The selected device is not currently supported in LineageOS 16.0": As one sees, it is also suggested that only LineageOS 17.1 is supported on the Pro1. However, a stable build of that does not seem to be available yet, as far as I know. Have updates of 16.0 been abandoned in the process of porting 17.1 to the pro1?
  23. Oh, very sorry to read that. 😢 I will try to replicate your scene and reproduce the bug using my device as soon as I have time to do so. There are several options related to HDR in the "Photo settings" submenu of OpenCamera. Especially the one named "HDR contrast enhancement" seems interesting to me: it defaults to the setting "smart" (whatever that means). All the way down in the menu (under "Debugging options") there is one more: "Enable fast HDR/Expo burst". Did you try to mess with those settings yet? Also the option: "Save all images for HDR mode" could be interesting
  24. Thanks for the warning, Eske. In fact, I practically never use HDR. I still learned photography on film, therefore HDR pictures have an "unnatural" look for me most of the time. Matter of taste of course. With that being said, I could not reproduce your bad experience in a few initial tests. E.g., when I take an HDR picture from inside of my room towards the window, both the interior of the room as well as the bright-daylight world outside come out correctly exposed, with no shadow around the window frame. So HDR seems to work at first glance. But, as I say, I am not an experienced HDR ph
  25. Update: 10 days later, I can report that OpenCamera has mostly settled my issues with the Pro1 as an "always-carry-on" camera. The "focus locked" program of OpenCamera works very well with the Pro1's double-action shutter button, and allows me to take sharp pictures also of quick-motion scenes. If needed, OpenCamera offers many more possibilities of manual control (exposure lock, ISO sensitivity, ...), but I rarely have to use them in daylight conditions. I'm also under the impression that focusing is faster than with the built-in LineageOS app, though I am not sure if this makes sense as I th
  • Create New...

Important Information