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.

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.

Just found this:

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

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

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

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