Suggestions for improvement

[Djhg2000]

After some experimentation in my own fork, then returning to regular Mobian, I've come up with some suggestions for how to improve Mobian which I don't think belongs on the bug tracker, at least not without some discussion first.

1. Replace Fractal with the flathub version of Nheko. This brings E2E support but it doesn't fit in the general theme of Phosh. The version from the repo segfaults and I've been unable to make my own builds work any better.

2. Copy over the udev rules from PostmarketOS to create EG25 symlinks in /dev/. I don't know if it's useful to anyone else but I feel more comfortable using the symlinks than trying to remember which ttyUSB[0-3] is which.

3. Periodic wakeup from deep sleep (perhaps we have an RTC we can trigger?) to refresh notifications from email and such. Even something like 30 minutes of sleep and a few seconds of activity with the display turned off before going back into deep sleep would help for me to keep track of my emails. Might not be frequent enough for instant messaging but I'll leave that up for discussion. Ideally this would be configurable.

4. GPSd. This is a big question, do we want it or not? Many desktop applications use it but they have questionable value on such a small screen anyway. Not sure if it breaks the new ModemManager style location access but the GPSd tools "gpsmon" and "cgps" have both helped be debug bad GPS reception.

5. Side arrow keys on either side of the space bar. I've already implemented this in my fork (where I also adapted the improved terminal keyboard to get the full screen width) but some people might find them annoying.

6. Have a preloaded whitelist for applications which should scale automatically. For instance, Maps is pretty useless without scaling turned on. When upstream Phoc/Phosh figures out how to solve this we can just remove the whitelist.

7. I've found that doing a renice of the "phoc", "phosh", "squeekboard" and "calls" processes I get what feels like a much more responsive system. I haven't found anything it interferes with yet but I also haven't had time to set it up to be automatically applied after boot.

8. Call recording. This was one of my pet peeves with Android, being designed specifically to prevent call recording. Mobian doesn't have those restrictions but since I had a huge pile of work to do dropped in my lap about 2 weeks ago I haven't had much time to figure out how the audio routing is done. Ideally I'd record the two sound streams going in and out of the modem directly as separate channels to a stereo file, which would make it easy to import the audio into Audacity if I'd ever need it. This might be better suited upstream in the calls app rather than in our local version, but I'd need to know how audio routing is implemented first.

9. Easy Anbox setup. I know this is a controversial issue but there needs to be a more streamlined setup process. I could throw together a quick script to do it semi-automatically but it's pretty useless if it doesn't result in more eyes on the Android app support. There are still a couple of Android apps which I need until we have suitable replacements, notably Slack and Signal with support for calls. Even with Anbox installed the Android apps have issues with audio. I don't know what to do about this, all I know is that I can't ignore the issue anymore.

10. VAAPI for hardware accelerated video decoding. I was working on this until 2 weeks ago and hit a brick wall when the Aarch64 GNU assembler refused to cooperate with me. The code doesn't look that hard to understand so I still want to take a shot at it but with a different approach; instead of porting to Aarch64 I could port it over to generic C code. The reasoning here is that i think it was made in assembler to begin with because it was supposed to run on very low end ARMv7 chips where every instruction counts. Our A53 cores a a lot beefier than that and while I'm not saying we can waste cycles, I think we can leave it up to the C compiler to optimize the code better than I can. Any help with this is very welcome.

Some of these are fairly straight forward changes while others are longer term projects. Please comment on these even if you disagree with me, feedback on things like these is important. I will open GitLab issues for the features people want and go back to the drawing board for the rest of them.

[a-wai]

You have quite good points here, let me answer with my personal views on the matter (which do not necessarily reflect the project's orientations when these subjects will be discussed):

1. Replace Fractal with the flathub version of Nheko. This brings E2E support but it doesn't fit in the general theme of Phosh. The version from the repo segfaults and I've been unable to make my own builds work any better.

That's a no-go for me: as it has been pointed out lately, flathub contains proprietary software, so each user should get to choose whether he wants to enable it or not.
Furthermore, I'd rather have more/better deb packages than flatpaks, especially in the default image.

2. Copy over the udev rules from PostmarketOS to create EG25 symlinks in /dev/. I don't know if it's useful to anyone else but I feel more comfortable using the symlinks than trying to remember which ttyUSB[0-3] is which.

I can't see the use for this: ModemManager should be the only software talking to the modem, and it already knows about each ttyUSB* role.

3. Periodic wakeup from deep sleep (perhaps we have an RTC we can trigger?) to refresh notifications from email and such. Even something like 30 minutes of sleep and a few seconds of activity with the display turned off before going back into deep sleep would help for me to keep track of my emails. Might not be frequent enough for instant messaging but I'll leave that up for discussion. Ideally this would be configurable.

I have no idea how to implement that (well, maybe a rough idea), but this would be indeed a welcome addition. I'd leave that subject for later (i.e. when we have reliable suspend/resume), but it's definitely an idea to keep in mind.

4. GPSd. This is a big question, do we want it or not? Many desktop applications use it but they have questionable value on such a small screen anyway. Not sure if it breaks the new ModemManager style location access but the GPSd tools "gpsmon" and "cgps" have both helped be debug bad GPS reception.

See above: ModemManager is in charge here. If gpsd is needed for debugging purpose, I trust the user will have the necessary skills to install and use it.

5. Side arrow keys on either side of the space bar. I've already implemented this in my fork (where I also adapted the improved terminal keyboard to get the full screen width) but some people might find them annoying.

This is something for upstream squeekboard. As long as it gets accepted upstream, I'm fine with it

6. Have a preloaded whitelist for applications which should scale automatically. For instance, Maps is pretty useless without scaling turned on. When upstream Phoc/Phosh figures out how to solve this we can just remove the whitelist.

I'd love to achieve that, but couldn't find a way to do it yet as it's more complex than "enable auto-suspend by default", and maybe not feasible at all. Any help will be appreciated

7. I've found that doing a renice of the "phoc", "phosh", "squeekboard" and "calls" processes I get what feels like a much more responsive system. I haven't found anything it interferes with yet but I also haven't had time to set it up to be automatically applied after boot.

I have mixed feelings about that: I don't doubt it can work and improve the overall responsiveness of the system, but it sounds a bit "extreme" to me. Definitely something worth discussing, though.

8. Call recording. This was one of my pet peeves with Android, being designed specifically to prevent call recording. Mobian doesn't have those restrictions but since I had a huge pile of work to do dropped in my lap about 2 weeks ago I haven't had much time to figure out how the audio routing is done. Ideally I'd record the two sound streams going in and out of the modem directly as separate channels to a stereo file, which would make it easy to import the audio into Audacity if I'd ever need it. This might be better suited upstream in the calls app rather than in our local version, but I'd need to know how audio routing is implemented first.

This is indeed something for upstream calls.

9. Easy Anbox setup. I know this is a controversial issue but there needs to be a more streamlined setup process. I could throw together a quick script to do it semi-automatically but it's pretty useless if it doesn't result in more eyes on the Android app support. There are still a couple of Android apps which I need until we have suitable replacements, notably Slack and Signal with support for calls. Even with Anbox installed the Android apps have issues with audio. I don't know what to do about this, all I know is that I can't ignore the issue anymore.

I don't think it would be that good to make Anbox easier to setup/use right now. The project is still far from being ready for prime time afaik, and I fear making it easy to install would lead to a storm of bug reports. Anyway, I believe the best way to tackle this issue would be to contribute to the Debian packaging or upstream project.

10. VAAPI for hardware accelerated video decoding. I was working on this until 2 weeks ago and hit a brick wall when the Aarch64 GNU assembler refused to cooperate with me. The code doesn't look that hard to understand so I still want to take a shot at it but with a different approach; instead of porting to Aarch64 I could port it over to generic C code. The reasoning here is that i think it was made in assembler to begin with because it was supposed to run on very low end ARMv7 chips where every instruction counts. Our A53 cores a a lot beefier than that and while I'm not saying we can waste cycles, I think we can leave it up to the C compiler to optimize the code better than I can. Any help with this is very welcome.

Feel free to get in touch via PM, I'll help as much as I can. Have you checked this page already?

You can also drop by on IRC/matrix to have a "live" discussion about those issues (and maybe others), we value any input and help

[patrickjquinn]

Point 7) I fundamentally agree with this. components of the core experience such as the shell and the keyboard should always have higher priority than other, less foreground bound services.

I'd also like to add a point. Have we looked at KSM out of the box? From my testing it make a noticeable difference.

[arturo2bodegas]

as someone who really wants to put his sim back into the pinephone to start using mobian as a daily driver, I'd love to see app scaling for already available deb software, but being able to use snaps and flatpak would be rad, too. I second that using the installed maps app would be handy if it would scale. 

I managed to get the xrandr scaling thing working, but couldn't get an app built to easily switch scaling quickly. 

does modem manager handle gps, too? gps would be a nice feature for navigation. the installed maps app puts a blue dot on the map, but it's about 200-300 meters off from my real location. 

one thing that I've noticed is that powering down from phosh (clicking the power off at top right of screen) does NOT actually power off the phone...I have to hold the power button for several seconds to do a hard shutdown, otherwise the screen turns off but the phone stays on and drains the battery down to zero.

all in all, mobian is getting better every time I apt update/upgrade! I'm getting closer to being able to take my sim out of my android phone and put it in my pinephone!

[wibble]

does modem manager handle gps, too? gps would be a nice feature for navigation. the installed maps app puts a blue dot on the map, but it's about 200-300 meters off from my real location.

Yes and no. It handles location, potentially including gps, for those applications using the right API. I _think_ maps uses Geoclue for location, which in turn tries to get it from ModemManager among others. Unfortunately the GPS is pretty bad at getting first fix, so the location you're seeing has probably been inferred from cell ids and/or wifi ssids. This may improve when we can get ModemManager to prime the gps with downloaded data along withturning it on and off. So far as I know ModemManager doesn't provide a compatibility API for applications expecting gpsd, so for navit, foxtrotgps and so on you need to set that up manually.

[a-wai]

as someone who really wants to put his sim back into the pinephone to start using mobian as a daily driver, I'd love to see app scaling for already available deb software, but being able to use snaps and flatpak would be rad, too.

App scaling is already a thing, as well as flatpaks (you only need to configure flathub).