@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