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 Desktop Packages, which is subscribed to network-manager 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 -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
