...or sundry ramblings surrounding the effect of hallium/android version, community interest, and my own ignorance on the future prospect of usb-c video out.

/

Having nothing to show for the $900 I burned a chasing the Fxtec Pro-1x convergence dream, and some amount of money coming in on the horizon, I find myself trying to decide where I will burn my next thousand dollars towards a usb-c pocket computer that also works untethered... on the road, and as a phone.

I understand that the fairphone 4 is currently the posterchild for european convergence, but that it does not work well in North America. Also, I kinda hate that they removed the headphone jack, but if it were just that I would probably dive into FP4 even now.

After some introspection, I think I have settled on the following pretentious list of requirements:

• unlockable bootloader (preferrably without diving into bootleg windows software from XDA forums)
• true wired usb-c video out (hdmi, displayport)
• sd card support
• north-american cellular frequencies
• votle-capable (any recent-ish phone)
• 3.5mm headphone port

So my first question would be to know of any more brands or phones that generally meet these requirements.

The closest hint I've got is that Sony hardware still has many of these vanishing features. So I started digging into Sony phones and stumbled across this list of sony phones that support video-out:

• https://www.sony.com/electronics/support/articles/SX912901

They are:

• Xperia 1
• Xperia 1 II
• Xperia 1 III
• Xperia 1 IV
• Xperia 5
• Xperia 5 II
• Xperia 5 III
• Xperia 5 IV
• Xperia PRO
• Xperia PRO-I

Given that the list is from sony, I suspect this to currently be a complete list of covergence-capable Sony smartphone hardware.

I found none of these in the hallium device repo.

I notice that two of them are currently supported by lineage os:

• Xperia 1 II
• Xperia 5 II

/

I know it's a long-shot to buy hardware in the hopes of future support, and unpredictable future, etc; but maybe it will even spur me to finally try porting a device myself, and subsequently inspire somebody else to continue the work for me

My secondary question is: would any of the above devices be more likely to be supported in the future than the others?

For example: the Xperia 1 & Xperia 5 originally shipped with Android 9, and I recall hearing in a Q&A that was a big deal. Is that still the case, or would the Hallium 9 barrier so likely to be broken in the next N years that it is not even worth considering?

Or perhaps... if there is a "moving target" effect, would the newest one be most likely (given a longer effective utility life)?

A related question might be: Is there anything that would make one or more of these devices easier to port?

Or is there any particular community interest in one of these devices over another? (e.g. maybe a lot of people have one of them already)

Or is the dream out of reach... is VoLTE still an issue? Perhaps it would be better just put the $1k from my next disappointing hardware purchase into a UBPorts donation? ... which, in hindsight, I wish I had done with the pro-1x money...

/

EDIT: Additionally, I have found that the Motorola Moto G100 might be the only Motorola phone that meets the above hardware requirements, with the added caveat that unlocking the bootloader requires registration with Motorola. However, it apparently comes with a proprietary covergence thing they call "ready for". So now I am wondering if I can have my proprietary convergence while the liberating one is incubating.

/

EDIT2: There may be some Samsung S10 phones that have proprietary convergence (samsung dex) AND already have some ubuntu touch porting work done... very promising.

@flohack It worked with OTA-3, both originally and after reverting from the newer rc/devel channels upon noticing the breakage... so that makes me think that it cannot be missing/corrupted partitions. Although, it is interesting, the implication that those are not included in the ubports install, so maybe I just have a different/older version.

I had a moment to get some diagnostic output (below), and am posting it here since I did not see it elsewhere on the forums.

[   38.163265] wlan: loading driver v3.8.20.24
[   38.178395] wlan: [898:F :HDD] hdd_parse_config_ini: request_firmware failed -2
[   38.178919] wlan: [898:F :HDD] hdd_wlan_startup: error parsing wlan/prima/WCNSS_qcom_cfg.ini
[   38.179431] wlan: [898:F :HDD] hdd_driver_init: WLAN Driver Initialization failed
[   38.190196] wlan: driver load failure

(OTA-4)

I have not had a chance to experiment with other releases yet, partly because it is far more difficult to get a release on the phone without wifi, but this was meant more as a report than a support request. Since I have already had to stop using UBPorts for daily driving.

I acknowledge that wifi may only be broken FOR ME, I thought that went without saying. I'm just trying to give help, not receive help.

@pitter121 Thanks. Since posting this, I did have OTA-4 present itself (which in and of itself I thought strange b/c I was expecting for it to just jump to 6), but updating to ota-4 broke the wifi. So at least we know the wifi issue was introduced between 3 & 4. I'm actually a bit surprised that it is not a known issue. Anyway, now I'll need to do some reverse tethering, a lot of cell-data-use, or just use the phablet flashing tool to get the device to be usable again.

I noticed (somewhere) as call for bacon testing, so I thought I might report my present experiences.

Updates: stable channel still says that ota-3 is the latest (and I think we are at 5 or 6 now)

Wifi: has been broken since (roughly) rc24 [up to (at least) development channel release #626]

txt/mms/calls: when the device is in deep sleep (dozing?), it does not receive phone calls or texts

Cheers.

If I could add anything to this discussion it would be:

• there should probably be a step-zero (update to xenial/16.04)
• there is an unfortunate spelling error in the first sentence regarding what we need... @mariogrip ...
• I wonder if "microG" would benefit us, as they have (to my understanding) a pretty complete open source google play services re-implementation, and only requires a minor kernel patch (to spoof google's SSL certificate); and it is supposedly far more trim and performant than the true-google variant

It seems like every device I buy has a used-up battery, and every battery I buy is aweful. It seems like every vendor is reselling old/dead/used-up batteries as new.

So far I have bought three phones for the sole purpose of ubports (at least two (nexus 5 & oneplus-one) are listed on best-support page), and a box full of no-good batteries.

But I feel like I must be doing something wrong... or not "into" some open secret (like everyone with continuous-use external batteries, or aftermarket battery manufacturers).

How are you even using these phones, long term, as "daily drivers" without power?

Is the situation different in Europe? Is there a magic product/service that converts a stock phone into using a commodity battery? What am I missing?

It occurs to me that this might also help those interested in automated app testing.

So here is what I'm currently considering...

For discussion purposes, I'll give them labels:

Plan-A: minimal work, a bit hackish, but fully formed plan

• Use the existing screencast api (DisplayName::virt) channel to get the visual contents of the screen over the mir socket
• phablet-control project starts as a fork from the mirscreencast (or mirscreencast_to_stream) utility
• waypoint: phablet-control causes the screen contents to appear in a 'remote' x11 window (so can't use DRI, xv, or the like)
• find or create a protocol (protobufs) for sending key/click/mouse-position
• if a magic socket path is found, phablet-control will send the relevant x11 events back to mir-android-platform (thus, phablet-control will work in a degraded view-only state on a phone w/o the mir-android-platform modifications)
• mir-android-platform is modified to create-and-listen on a magic socket path, and interpret events therefrom
• the window will not be resizable, and will always show what is on the screen
• there will be a whole lot of network traffic even when idle, since we are basically pushing an uncompressed video stream through it
• use of x11 implies no special app is needed on the PC side

Plan-B: more work, more unknowns, better result

• create a fourth display in mir-android-platform: DisplayName::remote (?)
• replace this step with the results of bribing Alan to disclose the rest of plan-b
• resizing the x11 window gives you more/less space (like tablet/desktop mode)
• comparing with the previous screen image might save a lot of bandwidth when idle
• use of x11 implies no special app is needed on the PC side
• since the phablet-control binary is on the phone, we don't have to worry too much about protocol breakage (its upgraded along with the mir-android-platform)

Plan-C: forget x11, USB is faster & more reliable

• convince marius to bundle socat with the default image
• mir-android-platform gets a new socket w/ undetermined protocol (maybe SPICE?)
• phablet-control now lives on the PC side, and basically communicates with the socket by starting a child process with:
  • adb shell socat UNIX-CONNECT:/run/phablet_control STDIO
• more bandwidth means happier users
• wired means less prone to interference (either way)
• lack of x11's network transparency means less flexibility (like controlling your phone you left in the other room)
• now we don't need the x11 libraries on the phone side

Alan said this, quite relevant, in the github issue:

The phablet-control program does not need to inject a platform into the Unity8 process, it simply connects to the hypothetical, modified "mir-android-platform" using some as-yet-unspecified mechanism (probably a local socket).

I'm happy to find that the mesa-x11 packages are already built for arm, and available to the phone... the actual amount of code that needs to be written for this might be incredibly small!

phablet@ubuntu-phablet:/$ apt-cache search mesa | grep -i x11
mir-platform-graphics-mesa-x4 - Display server for Ubuntu - platform library for X11 Mesa
mir-platform-graphics-mesa-x5 - Display server for Ubuntu - platform library for X11 Mesa
mir-platform-graphics-mesa-x6 - Display server for Ubuntu - platform library for X11 Mesa
mir-platform-graphics-mesa-x7 - Display server for Ubuntu - platform library for X11 Mesa
mir-platform-graphics-mesa-x8 - Display server for Ubuntu - platform library for X11 Mesa
mir-platform-graphics-mesa-x9 - Display server for Ubuntu - platform library for X11 Mesa
mir-platform-graphics-mesa-x10 - Display server for Ubuntu - platform library for X11 Mesa

In the interest of linking both sides of this reference, I've opened a request-for-comments from the mir group, since they surely know way more about this than me:

• https://github.com/MirServer/mir/issues/430

@gizmochicken ... It's rather interesting, but can that really be expected to ever work with ubports? I don't think UBports even has java, by default, much less implementing these special attachment points:

import android.annotation.SuppressLint;
import android.graphics.Point;
import android.graphics.Rect;
import android.media.MediaCodec;
import android.media.MediaCodecInfo;
import android.media.MediaFormat;
import android.net.LocalServerSocket;
import android.net.LocalSocket;
import android.net.LocalSocketAddress;
import android.os.Build;
import android.os.IBinder;
import android.os.IInterface;
import android.os.RemoteException;
import android.os.SystemClock;
import android.util.Log;
import android.view.InputDevice;
import android.view.InputEvent;
import android.view.IRotationWatcher;
import android.view.KeyCharacterMap;
import android.view.KeyEvent;
import android.view.MotionEvent;
import android.view.Surface;

Yes, @gizmochicken ... something very much like Vysor... but (hopefully) without the huge web browser, and open source.

No... I'm not really interested in x11 forwarding (for the same reasons you mention).

Although... originally, I was thinking there would have to be something special on the computer side for this to work (like a mir server), but I wonder how difficult it would be to make an adapter (similar to what you mentioned), that would expose a new mir display over an x11 display protocol.

Sorta like a hacked-down version of miral... or the "opposite" of xmir.

Then you could do something like:

ssh -X myphone phablet-control

... and the 'phablet-control' binary would add a mir platform (as you mention), and present itself as an x11 frame (e.g. the window size is the reported display size, etc.); and then you wouldn't even need anything special on the PC side!

@alan_g ... If I understand you correctly, this socket-sharing mechanism would then only work for the most trivial case (like an "hello world" example app); because anything that actually tries to interface with an expected phone-like gizmo via mir would not find it.

Thanks @matteo ... I am aware of X forwarding, but not how it might be leveraged to actually use any of the touch apps.

So this is as far as I got... apparently there is a version mismatch between ubports and upstream mir, so ATM this does not work.

Once: install mir on your PC

sudo dnf install mir-demos qterminal socat

Once: install socat on the phone

adb shell
sudo bash
<enter unlock code/password>
mount -o remount,rw /
apt-get update
apt-get install socat
mount -o remount,ro /

Each time

miral-app
SOCKET=$(ls /run/user/*/miral_socket)

socat UNIX-CONNECT:$SOCKET EXEC:'adb shell socat STDIO UNIX-LISTEN\:/tmp/display2,reuseaddr' &

adb shell MIR_SOCKET=/tmp/display2 unity8-dash

FAILURE

mirserver: Rejected and disconnected a client (Unsupported protocol version)

Oh... I see... there is no control channel. This is the wifi display link, the miracast protocol or a hardware dongle, etc.

@tera said in Reverse Convergence? View & control your phone from computer (like VNC & RDP?):

Convergence over wireless

Is there a place I can find out more about this wireless convergence? This is the first I've heard of it!