touch-packages team mailing list archive

[Tony Espy <1480877@xxxxxxxxxxxxxxxxxx>]

So the latest changes in Lorn's signals6 patch can be summarized as:

1) remove QNetworkManagerEngine::requestUpdate (), which is a public
method which can trigger a WiFi scan request to NM.

This method doesn't appear to be called internally by the bearer plugin,
so if we think extra WiFi scans are the culprit, there must have been an
change to one of our Qt applications which is calling this method.
Also as this method wasn't added in the original patch, it's presence
can't really be considered a regression.  Has anyone attempted to
determine if we *are* scanning more often?  This could be done manually
by running wpa_cli ( as root ), and watching for the frequency of scan
events output.  It can also be accomplished by looking at the wpa_suppl
and/or NM log messages in syslog.   And finally, you could also just
monitor DBus looking for ScanDone signals from NM.

NOTE - I'm pretty sure this patch won't compile unless this method is
also removed from qnetworkmanagerengine.h too, but I haven't tried to
build it myself...

 2) check that wiredDevice pointer is valid before using it to call a
method

This is the crasher fix when USS/Qt from the PPA gets installed on a
desktop.  Looks fine to me.

 3) remove most of the logic from the engine's parseConnection() method.
This method takes a connection path, and creates a private configuration
object, and then based upon the underlying device type, may modify the
private configuration instance in a device-specific way before returning
it to the caller.  The device-specific logic in some cases could have
side-effects, such as modifying the global accessPointConfigurations
hash table and/or the configuredAccessPoint map.

Again, this chnage looks reasonable to remove, however I don't see how
it could have any impact on power.   This code only runs during
initialization where all existing system connections are loaded, and
whenever a new system connection is added ( ie. a user connects to a new
AP or APN ).

I'm not sure whether we want to include this the last change if we want
to keep the delta as small as possible?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qtbase-opensource-src in
Ubuntu.
https://bugs.launchpad.net/bugs/1480877

Title:
  Access points' "PropertiesChanged" dbus signals freeze UI on mobile
  devices

Status in Canonical System Image:
  Fix Committed
Status in Unity 8:
  New
Status in dbus-cpp package in Ubuntu:
  In Progress
Status in network-manager package in Ubuntu:
  Incomplete
Status in qtbase-opensource-src package in Ubuntu:
  Fix Committed
Status in dbus-cpp package in Ubuntu RTM:
  Fix Released
Status in location-service package in Ubuntu RTM:
  Fix Released
Status in network-manager package in Ubuntu RTM:
  Incomplete

Bug description:
  Krillin, rc-proposed, r83

  
  DESCRIPTION:
  I've been trying to track down the cause of the occasional UI freezes on my Krillin device, and I noticed that whenever the UI freezes for 2-4 seconds, I get a burst of "PropertiesChanged" signals in dbus-monitor

  Here's a log of what's shown in dbus-monitor:
  http://pastebin.ubuntu.com/11992322/

  I'd guess the problem is in the code that actually catches the signals
  and acts accordingly.

  HOW TO REPRODUCE: 
  1) Move to a place where many wifi hotspots are available
  2) Connect the device via USB and run "phablet-shell" and then "dbus-monitor"
  3) Use the device while keeping an eye on dbus-monitor output

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1480877/+subscriptions