Ordinarily, we think of convergence as your phone being your workstation, when connected to the appropriate hardware; and this is desirable b/c a keyboard & mouse are far more effective than a touch interface... it's just quite bulky to carry around in your pocket. In this case the phone is in-charge, and doing everything.

There are a few problems with this, of course... for one, no matter how good phone processors get, they will never have the speed/memory/graphics of a PC. Another is that your 'workstation' is not useful without your phone... so you have no backup, and anything that occupies your phone (like a call) could interfere with your ability to use your workstation.

At the moment, the only true convergence I feel is on the command line. UBPorts stomps all over the Android shell, and I can open it remotely (ssh) or over usb (adb shell)... scp'ing files to-and-fro. It is truly a world-class app, and (ironically) 1000x more effective and easier to use from my computer than on the phone itself!

And that got me thinking... my phone's shell, in effect, is presented to me as any other shell... like any other SSH session... couldn't (roughly) the same thing be accomplished by just reversing the master/slave convergence relationship?

I already have a fine PC, and I'm already quite used to using virtual-machines (machines inside windows on my PC), so if I could "just plug in my phone and its screen pops up as a window" (like any other VM)... that would happily solve the majority of my "convergence problems".

There are so many little tasks that require "switching to my phone"... looking up a contact, getting a MFA code, changing an alarm time...

It would be so much more effecient if I could just do that from my computer, without having the mode-switch, focus-change, unlock-phone, hands-off-keyboard/mouse, swipe/tap, type-on-the-tiny-onscreen-keyboard, etc.

Then I wouldn't need a 3rd party app (or service!) to "send an SMS from my computer", or any complicated setup to sync my contacts & text messages... or... anything that my phone already can do well. Truly making workflows mobile-first (as anything I can do on my phone, I can then do on my PC).

...and if you think about it... even though the complexity is about the same, this offers you more functionality than classic convergence. It opens the door to copy/paste between your phone & PC... while keeping you used to (and in fact, using) the same apps that are on your phone. I'm so excited at this prospect, I can already imagine even the unity8 live-resize demo (where the interface changes from touch to windowed depending on screen size) only powered by a device I can unplug and take with me!

There are probably several ways to implement this, and I would love to hear of anyone's efforts at even basic remote control.

I've seen the mirscreencast binaries, so I imagine this is at least technically feasible.

I so pine for what I might express as:
ssh -X myphone unity8

I've been looking for a good touch-oriented linux distribution for my x86 tablet for those times that I do not have a keyboard & mouse.

Including:

• KDE Plasma Mobile
• Android-x86
• MaruOS
• LuneOS
• ...and probably more that I'm forgetting ATM.

From my experience with UBPorts on my Nexus 5, I think that it might be a good fit; but the only "ubuntu touch on x86" references I can find are from the now-defunct canonical side.

As I understand it, most of the (non-touch) packages can be upstream ubuntu, and this probably 85% overlap with ubports unity-on-the-pc goals... so I imagine supporting ubuntu touch on x86 might be as simple as having the packages compiled for that arch, a PPA available, and a wiki page... and I also think that having a qemu image could help others looking to experiment with UBPorts without a hardware investment (or specialized development workflows).

Does anyone have more information on this (or even know of the requirements/pre-reqs)... it is definitely something I am interested in pursuing.

I would also be interested in knowing of any other distros-or-projects working on mir-on-x86, as that would probably be a half measure towards this goal.

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

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

@advocatux Yes. I noticed that. It is clearly an incomplete proof-of-concept, but it the closest thing I have found to "remote control" thus far.

Just found this:

• https://github.com/ycheng/mir-vnc-server

This trend seems to good to be true, and the fact that there is no negative movement (only flats) makes me think it might be accumulating rather than measuring.

e.g. if the stats per month is "where time<=month", rather than "where month(time)=month", or if there is a missing "stats.reset()"... I have no idea how/where this is implemented, but I would be interested in seeing the actual counting code.

Also, the way it is spec'd makes me think that my one device, whenever it gets a new address (leaving home wifi, rejoining the cell tower network, and maybe even rebooting or roaming to a new super-cell) will count as a new device.

I might notice how frequently my phone's ip changes, for this sake, but I assume that in the common case (which I assume is wifi+cell) the actual numbers are at least (and almost automatically) half what is reported.

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