claude0001

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.

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

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

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

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

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?

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

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!

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 ...