Oneplus 7 Pro

[tophe...@gmail.com]

Greetings Preetam, Georgian and Deepak! Some news on GM1917 - pretty much bug-free thus far, albeit with SELinux permissive and adbd=1 to make some adjustments (sorry to bork the proper thread, but I couldn't respond to the last one) 

The only notable "bug" has come up has been discussed previously, the link between mflinger/mclient and Android's native window manager. Like the other post, I too have been stuck at 1280x720 on the stock Debian image. After doing some digging, I found that Georgian's Ubuntu image defaults to 1080p (couldn't get lightdm to start, but resolution was pegged at 1080p in two places), so I tried one more thing, and this is the confusing part. There's a tiny binary called "edm" one can use to manipulate external displays on Android. It behaves exactly like wm (from tytydraco on GitHub). So 'edm size' reports a default of the physical size of the display Debian is connected to, and the Debian desktop is not scaled or stretched to that size, but rather the native 1280x720 that occupies the proportionate amount of pixels. However, 'edm size 1280x720' will fill the entire display, provided it's the same 16:9 ratio. I have a superultrawide that just for fun, tried using 1280x368, which filled the entire display, but at that resolution (or the stretched image, I think). 

Very small potatoes in contrast to where Maru appears to be headed. Preetam and Georgian, in case you don't remember, I was one of your anxious HTC10 enthusiasts, and as (terrible) luck would have it, after you took the time and energy to walk me through everything, it was stolen not even a month later. Ugh. Anyhow, even with that device, it was pretty easy to see just how performant your implementation of LXC and the graphics buffer is. Fast forward to today, a few QC SD chipset generations later and 3x the RAM, Maru desktop is indistinguishable from most Chromebooks, and even some Intel Core ultrabooks from the last few years (for most tasks, haven't tried Blender yet). 

Granted, the chip only has to 720p to manage, but it doesn't even flinch. Even when using the scrollbar on Firefox like it's a slingshot (fairly complex webpage, with a ton of content), HTOP is showing less than 50% on the little cores (zero on the bigs) and a whopping 3.5gb total RAM usage between the phone and desktop! Inconceivable. If it's possible and okay with you guys, I'd like to try mounting multiple containers. Or is mflinger/mclient written for a single instance and container in mind? If so, I've heard libvirt does quite well with limited resources and multiple containers.

Or, I noticed that there's another patron here named Twaik who proposed an idea that sounds a lot like an xWayland client that was floating around the xda forums for a while. I tried it with a chroot, and it's impressive, though the dev that introduced it seems to have vanished from both xda and gitlab. I still have the Android app somewhere, so if you think it would be something worth testing, I can certainly dig through the embarrassing amount of backups on flash drives I've accumulated over the years instead of using a proper server or NAS, like a grown-up. 

@Deepak - It seems like you stuck pretty close to Lineage's defconfig, with the obvious additions to the cgroups, or did I diff the wrong one? Also, I wasn't sure how it would pan out, but I used f2fs for the data partition, and as usual, it flies. I just wasn't sure how it would do with an entire rootfs on it, which is a first for me. If you try as well, remember to adjust the fstab (when I switched to f2fs, I forgot to remove nosuid).

Okay, sorry for the novella, fellas. Please let me know if there's anything I can do that might be remotely helpful, though I suspect that's like asking Superman if he needs a gun. Hope all is well! 

[Preetam D'Souza]

Hello tophersucks, it is great to hear back from you! Of course I remember you from the early days!

This is great news to hear that Maru runs so snappily on the OP7 Pro.

Regarding the 720p resolution, this could be because mclient is unable to sync the correct display resolution from mflinger - in this case it falls back to 720p. If you check `journalctl -fxu maru-mflinger-client` you may be able to see some logs related to display size syncing and you can check for errors there. This fallback to 720p was introduced here: https://github.com/maruos/mflinger/pull/7. This was introduced due to a lack of API to obtain virtual display resolution from Android (you can only get it for the built-in screen and HDMI external displays) and we wanted to fall back to a reasonable default for virtual displays (aka wireless displays or chromecast). If you are connected over HDMI to an external display then things _should_ work at the display's native resolution, but it's possible something weird is going on on the OP7 specifically. Perhaps @Deepak can look into this resolution issue further with this info.

I haven't been able to post on here that much lately due to other work I've got on my plate but am really thankful people like you and the rest of our awesome community is doing so much great work to get Maru on the latest hardware and help test community builds. We (me, @utzcoz, @pintaf, @twaik, @Georgian) are working on an official version of Maru 0.7 / LOS16 / Android 9 with some improvements around maintainability so we can bring all our official devices up to LOS16. Once that's done we will move on to LOS17 and can hopefully make OP7 official. A lot of our discussion is on GitHub nowadays so make sure to follow along there as well. Hope to have more news on this front soon.

Thanks as always for testing and the great feedback over the years. Really appreciate you, and all of the other amazing devs and testers on here, taking the time out of your day to help make Maru better. We wouldn't have made it this far without the incredible enthusiasm about Maru in this community.

Best,

Preetam