fyi: requestUpdate is called by the qnetworkconfigurationmanager, when
updateConfigurations() gets called.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to dbus-cpp in Ubuntu.
https://bugs.launchpad.net/bugs/1480877
Title:
Access poi
@Tony
1) requestUpdate() should be left in, as the backend needs to tell other parts
when the update request has been completed. I have tested this, so it does
compile. In further testing, it does not look like any clients are requesting
updates, so the increased power consumption is coming fro
patch #6 fixes crash in system-settings (#1523975) and removes wifi
scanning updates, which could potentially drain the battery (#1524133)
** Patch added: "net-bearer-nm-disconnect-ap-signals6.patch"
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1480877/+attachment/4531735/+f
@Tony I suppose that if statement in
QNetworkManagerEngine::requestUpdate() could also be removed, leaving
the last line only, since we do not do anything with uknown AP's
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to dbus-cpp in Ubu
@Tony, currently I am on stable/ubuntu-developer. Previously I was
testing on stable/ubuntu. I was on rc-proposed for quite a while, but it
seemed to have only a few scopes, and not the twitter scope which I
wanted to try out.
My updated patch removes actions on device added and removed calls. Mos
I changed my phones image channel, tested (with a few specific test apps
I have for QNAM & friends) that new patch and didn't see any thing too
wrong.
Although I am seeing heaps of GetAll calls that do not need to happen
(even for non nm managed interfaces - rmnet). Attached patch
simplifies/optim
@Tony
I noticed this on touch.
The problem was that the ConnectionActive was returning true for mobile data
ipv6 default route when wifi had the actual default route, so it would never
get updated when wifi became default.
--
You received this bug notification because you are a member of Ubuntu
Since it takes quite a bit of time to get a satellite fix, but it does
get one eventually (nexus 4 here), we can probably assume that it is
agps that is not working.
In the location log, I can getting errors such as:
E1123 16:30:46.685298 1232 android_hardware_abstraction_layer.cpp:157] Error
do
I agree, since nothing controls the connections through QtBearer (and
the platform doesn't want that), and AP lists are not allowed in
contained apps, it makes sense to simply remove them.
I've fixed up that patch in regards to d'tor disconnects, removed some
redundant code.
And since it was a sm
Sorry, thought I'd include more.
2nd patch that obsoletes my previous patch includes disconnecting from
system dbus when objects get deleted.
** Patch added: "nmbearer-fix-duplicates2.diff"
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1480877/+attachment/4521679/+files/nmbea
This patch fixes duplicate entries of access points. Which contributes
to but may not totally fix this bug.
** Patch added: "nmbearer-fix-duplicates.diff"
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1480877/+attachment/4521638/+files/nmbearer-fix-duplicates.diff
--
You rec
You are correct in that GetAll gets called twice for each accesspoint.
I can see that by adding qDebug's and disable/enable wifi
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to dbus-cpp in Ubuntu.
https://bugs.launchpad.net/bugs/148087
nmRegistered will only get called from the connection signal/slot when
networkmanager daemon if and when gets registered on the dbus. If it is
already registered, it will get called from that invokeMethod.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, whic
Actually, the only time Qt's QNetworkManagerInterfaceAccessPoint does a
GetAll is in the QNetworkManagerInterfaceAccessPoint c'tor. But that is
in the upstream version.
And the current ubuntu version (at least the one I am seeing) does not
do GetAll at all.
--
You received this bug notification
hmmm... I just noticed/remembered that upstream Qt networkmanager plugin
has been updated, which should perform a bit better as it has had some
refactoring/rewriting done. It is slightly more sane.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is sub
The generic bearer plugin is brain dead, especially when it comes to
knowing when it's actually connected or not.
Although connectivity-api also suffers from blocking dbus calls, I feel
the connectivity-api backend is the right way to go for bearer & QNAM
right now. In the least, it will lessen th
16 matches
Mail list logo
