claude0001
-
Content Count
554 -
Joined
-
Last visited
-
Days Won
66
Posts posted by claude0001
-
-
1 hour ago, Raksura said:
I thought libhybris was a replacement for (or at least part of) Mesa 3D so it would be compatible with the Android kernel.
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) run a desktop-Linux distribution on their phones, as those do not use libhybris but a traditional GNU/Linux graphics stack. And the latter -- understandably -- expects the traditional GNU/Linux kernel interfaces to be present in order to do HW acceleration (and they aren't).
-
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.
-
4 hours ago, Raksura said:
I took it to mean that once EGL buffers are properly integrated on the Android platform, hardware acceleration will become available to standard Wayland applications.
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.
This may seem like a primitive approach at first. However, that is the very design goal of Wayland: reduce the display manager to the minimally-required functionality to make it efficient and secure.
X11 provided its own rendering APIs for graphics and text and tons of other high level functions that made it powerful in its time, but also complex, inefficient and insecure. Moreover, nowadays all those X11-APIs have become practically useless, as programs prefer to use specialised (and hopefully hardware-accelerated) libraries for their rendering anyway, simply sending over the resulting bitmaps to X. Wayland essentially adopts this de-facto standard procedure as the "official" way to do graphics in Linux, and supports X11-style drawing APIs only via an (optional!) X-server that runs ontop of Wayland, like any other app (XWayland).
Do not worry though, your misunderstanding seems to be so widespread that it is in the Wayland FAQ:
QuoteWhat is the drawing API?
"Whatever you want it to be, honey". Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer. When the client is done, it informs the Wayland server of the new contents. The current test clients use either Cairo software rendering, Cairo on OpenGL or hardware-accelerated OpenGL directly. Additionally, media frameworks can share their buffers directly with the server. As long as you have a userspace driver library that will let you render into a shareable buffer, you're good to go.
-
3 hours ago, Raksura said:
[...] Hardware acceleration seems to be working on both SailfishOS and Ubuntu Touch.
[...] Applications ported to these systems are modified to match such restrictions [...]
[...] Once the Wayland interfaces get updated, I assume porting applications so that they support hardware acceleration will require little to no work at all.
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 hardware acceleration for the client programs running inside its windows. On standard (i.e. desktop) GNU/Linux systems, client programs rely on things like DRI/DRM (for accelerated OpenGL rendering) and VAAPI/VDPAU (for video decoding). As the Android kernel does not contain driver modules to support those standard interfaces, clients fall back to CPU rendering. Whether the resulting bitmaps are then handed over to X, Wayland or Mir for display is of no importance here. E.g. desktop apps running on Libertine in UbuntuTouch have no hardware acceleration for precisely those reasons.
For distribution-wide hardware acceleration on a closed-source Android basis (like the Pro1's), all relevant programs need to be ported in a way to use libhybris instead of the standard GNU/Linux interfaces. That is of course possible in principle and it is essentially what SailfishOS and UT are doing for their "native" apps (as far as I understand). But, again, my concern is not about phone/tablet OS's.
It seems that for desktop Linux distributions, there is (understandably) little interest in libhybris (read e.g. this discussion on Debian).
I admit that I am not really an expert on all of this, and I might be too pessimistic altogether. But hey, then life is full of positive surprises!
-
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 install. So, do you actually think your Sailfish setup is superior in terms of "hardware-support" to all the CHROOT/PROOT solutions for using desktop-Linux on Android? If not, what other advantages do you see?
* In your set-up, you seem to be using the touchscreen as a "direct input" interface. The standard way of using a (desktop) Linux-chroot on Android is to access an X-Session running in the chroot via a remote desktop (RDP or VNC) client. This is quite convenient, as most of those offer the possibility to emulate a touchpad, as well as several mouse buttons. Also, many clients allow gesture-based zooming of the Linux-session which is often useful given the small screen size. Is this possible using your XWayland solution on Sailfish?
* In Android, the security model can be nuisance in this kind of use case, as it prevents fully transparent mounting of Android filesystems in the Linux desktop environment at least for its "sacred" partitions (as far as I understand). How is it on Sailfish? Can you mount any filesystem of the parent OS in the container so that it is writable (for root at least)?
-
On 12/2/2020 at 1:17 PM, EskeRahn said:
Just curious. Any particular reason for not upgrading to 17.1 ?
On 12/2/2020 at 1:20 PM, PokeParadox said:Laziness... Also isn't the clock broken currently, or something like that? I figure it's running stable enough as it is, maybe I'll update after a few more releases! 😛
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.
-
1
-
-
11 hours ago, PokeParadox said:
[...] Is it possible you could clarify how you got XRDP to work as for me it is just complaining that it is in a CHROOT environment when I try to start the XRDP service.
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.
-
1
-
1
-
-
9 hours ago, Linkandzelda said:
The VNC client app I like to use for all connections is VNC Viewer, because it has no on screen GUI to block views. Some have little bars or dropdowns for touch screen interaction, and this doesn't. The server is Xvnc which I think is TightVNC or TigerVNC.
[...]
This is a HTML version of my vimwiki page of notes on the project which has a lot of config files and documentation on the fixes I did. Maybe it's useful for you: http://wiki.laz.li/shared/f994e9b960893079fd101fd05b9ca4e9b1569466973f998ca728b18eba3928e7
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 problems I never actually ran into. I installed my Chroot from scratch and do not use Linux Deploy. Maybe the latter comes with preconfigurations that do not work well in all cases.
One thing that is bugging me is that I am unable to get write access to Android file systems on the internal storage (like /storage/emulated/0) from the chroot, even as root. Is this working in your set-up? If yes, how are these filesystems mounted in your Chroot?
-
2 minutes ago, VaZso said:
Unfortunately, no.
It starts Snapdragon Camera.Yes, that button is a good to have, however, the similar button of N900 was better (at least the feel of 1st stage).
However, any phone is not really comparaple with a correct DSLR, but still camera button is a plus.
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-pressing the shutter button as described above.
P.S.: This might be getting off-topic ...
-
6 hours ago, VaZso said:
Right, unfortunately it is very likely because of the manufacturer of "Google Camera". 😞
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)?
-
9 hours ago, VaZso said:
Right, there are GCam mods which are much better than stock camera and also better than other solutions.
That way it can take really good photos.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-the-box camera experience with the Pro1 is not very nice, but it is not a show-stopper for me. Compared to my good ol' N900, it did (still does?) take quite some time to get used to the quirks of this camera -- but using OpenCamera I feel like I can get it under control. (And it's FOSS, yay! 😎)
-
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:
On 11/27/2020 at 7:09 AM, Linkandzelda said:[...] It is connected to via VNC, and the connection is pretty good. [...] I was even able to do some coding here and it was quite pleasant. [...]
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 fully support the Pro1 keyboard. Mostly, the level-3 key events would not arrive at the VNC server, hence making programming impossible. I was not able to fix this X-server-side (with xmodmap et al.). So I now wrap my VNC in XRDP and connect from Android using MS (sic) Remote Desktop 8. This solution works nicely for me (including the keyboard), but probably does add some unnecessary connection overhead. Are you on stock Android 9 or LineageOS now (asking as I think there are differences in the keyboard drivers)?
I agree with you that the Pro1 -- while making a remarkably useful miniature Linux computer -- does have its flaws as a phone. Mostly I am not happy about the bad quality of the main camera (mostly software problems, I guess) and the poor WiFi reception (manages to loose signal within my 40 m² flat, hadn't thought that was possible).
However, I think that despite these small problems, the Pro1 functions sufficiently well also as a "regular smartphone". This dual-use scenario (smartphone + GNU/Linux palmtop) is precisely what I was looking for in the Pro1, and I believe it fulfills this double role quite well (or at least better than all competitors I know of), so I have no second thoughts yet.
-
3
-
-
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-Server inside the Linux Chroot and then connect to it from Android via VNC or RDP, as you obviously tried yourself already. While also this does not solve the problem with Direct Rendering, it is in my regard a more stable solution, as startup and shutdown of the X-Server are under control of the Chroot, and do not depend on a separate Android App (that one might e.g. close by accident, killing all X11 programs). This also yields the possibility of being able to disconnect and reconnect a Linux session permanently running in the background.
I might migrate to UbuntuTouch when that becomes officially supported (or kind-of). That may solve some of the typical problems one has with a Linux-Chroot on Android (e.g. write access to Android-controlled partitions from Chroot is not possible for me, even rooted). But for now, I also run my Debian aside of LineageOS (16).
I posted my setup in another thread on this forum. It is designed for work, but listening to music is possible. My solution does take full advantage of the Pro1's keyboard. That's an important detail if you really want to do programming on your device, and it does not work with every random "Linux-GUI" solution unfortunately ...
-
1
-
1
-
-
On 11/22/2020 at 3:19 PM, piggz said:
Its getting a lot better. 3.4 updates the engine to esr52, and the next release updates again to esr60
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 is around, but for (business?) reasons I do not understand, Jolla try to do "their own thing" instead of basing their distribution on one of the big players (like Debian or CentOS). Wouldn't doing so remove the need to play catch-up on things (like gcc) that most (desktop) Linux users do not even perceive as a potential compatibility problem, because the big distributions just pick them up fast enough?
-
1
-
-
3 hours ago, EskeRahn said:
Different users, different usage patterns. When i tried out SFOS I do not recall if I even opened the browser.
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.
-
1
-
-
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 -- otherwise I see no future for the platform.
Let me emphasise that I very much appreciate the architecture and philosophy of SFOS otherwise. But, If I simply wanted a full-featured UNIX on my phone "just" lacking a decent web browser, I could as well continue to use my N900 ...
-
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 respect to the sensor (which is where said calibration comes in).
-
4 hours ago, fxtec-preorder-47xx said:
[...] I really think, I MUST have early-model hardware. I flashed SailfishOS on my Pro1 also, and there was NO CAMERA (black screeen in camera app) at all. (According to others, it should have been there and working normally.) So WTF is up with my hardware? [...]
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.
-
1 hour ago, fxtec-preorder-47xx said:
[...] Problem is that with my phone on LOS, there is no way to get focus right, even manually like "really close but not quite infinity." Always blurry. [...]
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 could go wrong there?
Up to now. I assumed that this kind of image processing was hard-wired in the "Scene Modes" that one can choose from, but now I am not sure anymore: in a few quick tests, my phone seems to take the same pictures even if I cover the secondary lens. Is the information from the second lens used at all in in LineageOS (16) or OpenCamera?
-
On 8/6/2020 at 12:04 PM, fxtec-preorder-47xx said:
[...] On BOTH (Stock and LOS) if you slide to 'infinity' the far objects get less sharp. [...]
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 scene mode to something else than "Auto" as suggested?
4 hours ago, fxtec-preorder-47xx said:[...] You mentioned "driver". What is this driver called? Who maintains it? What do you know bout it?
I do not know much about that. There is obviously a driver on the level of the Linux kernel that actually talks to the hardware. That one is probably (not sure though) a closed-source component. Then there are several abstraction layers that make the hardware accessible from Android. Finally, Camera2-API exposes the functionality to applications. [ https://source.android.com/devices/camera ]
Based on how things work on traditional (desktop-) Linux systems, I believe auto-focus is implemented either in hardware or on the driver level, but I am no expert on this.
As I wrote in a different thread, the camera is my biggest disappointment with the Pro1, so I share your suffering ... 😞
-
1
-
-
11 hours ago, fxtec-preorder-47xx said:
[...] ... still no proper focus. This is f##ked up. [...]
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 something smart at the moment of taking the picture, but fails. I can fix this by forcing a specific scene mode ("Portrait", "Landscape", "Action", ...) manually.
In the worst case, you can even disable auto-focus in OpenCamera and adjust the focal length manually. I agree that one would expect this not to be necessary in 2020.
-
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-issuesUsing 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 script to this post for reference). Doing this gives CLI access to Debian from any Lineage/Android SSH client. I mount the Android filesystems (read only) in the Chroot. There is a second, common partition on the SD-card writable from both systems for data exchange. The Chroot script also starts a background process ('aid_dns_syncd') that keeps Debian's DNS in-sync with that of LineageOS, so that internet access just works (tm) in Linux.
A CLI Debian is already a very powerful tool in itself, especially as it is accessible via SSH: it allows e.g. to automate backup tasks or transfer files to and from the device via SFTP. Still, this does not yet qualify as a "desktop" experience, of course.
So my Chroot script also starts an XRDP-server. The latter is ready to spawn a KDE/Plasma 5 desktop on request by any RDP client (although I specifically restrict this server to listen to localhost only). I found (paradoxically for a Linux enthusiast) that Microsoft's Remote Desktop 8 App provides -- by far -- the best support of the Pro1's keyboard because it is able to forward scancodes. VNC -- the usually recommended way of accessing a Chroot desktop -- did not work for me, as Android VNC clients (at least all that I tested) are unable to send the Pro1's level-3 keys (essentially the yellow symbols), which are important for programming. That said, my XRDP does use a (Tiger)VNC frontend that I found to provide the most stable X11 server, although more performant solutions (xorgxrdp) do exist.
Using Remote Desktop 8 to connect to Debian's XRDP service allows to use the Pro1 like a miniature laptop. Remote Desktop 8 can emulate a touchpad-driven cursor, which allows to operate conventional desktop software much more conveniently than when using the touchscreen directly (trying to hit minuscule buttons or icons by fingertip is just frustrating and IMHO not suited for a working environment). A nice side effect of using XRDP and the Microsoft App is that they are able to forward sound from the Debian chroot to the Android sound system transparently. This does not work out-of-the-box though, one needs to manually compile and install the respective PulseAudio drivers in Debian, as described here:
https://github.com/neutrinolabs/pulseaudio-module-xrdp
That audio set-up works well enough for listening to local music players or Youtube music. The video frame rate of the latter is bad due to the lack of hardware acceleration and (probably) because of the additional overhead introduced by XRDP. But as I have Newpipe and VLC on LineageOS, I do not really care about that: Debian is for work, Lineage for fun. 🙂
Edit:
Since writing this post, I migrated my set-up from Debian 10 to Devuan 3 as explained in this post. Because of its traditional server init scripts, I found the latter to be more suited for a chroot environment.
Updated the chroot startup script accordingly.
-
2
-
2
-
-
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?
-
1
-
-
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 other web pages.
-
2
-
Desktop Linux on Pro1 without sacrificing telephony: LXC containers in SailfishOS (video)
in General Discussion
Posted · Edited by claude0001
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, even though the filesystem is mounted rw in the chroot, and even if I try to write as root. I assume some higher-level Android security layer stands in my way here. I do have full write access to a separate data partition on my SD card, that I can thus use for data that should be read/writable from both systems.
As for HW accel: For the reasons I discussed with @Raksura, I still fail to see how having an accelerated Wayland compositor (the patched wlroots) would automatically give you hardware acceleration in the client apps, as I think that is completely independent of Wayland. But as I say, I am no expert on this. Just a long-time (desktop) Linux user whom this (otherwise marvelous) Pro1 with its proprietary kernel blobs reminded of the value of (truly) open-source software ...