Summary: | WiFi permanently disabled after hardware rfkill off and is no more re-enabled after rfkill on. | ||
---|---|---|---|
Product: | [Unmaintained] solid | Reporter: | Andrey Borzenkov <arvidjaar> |
Component: | networkmanagement | Assignee: | Sebastian Kügler <sebas> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gokcen.eraslan, korossy, lamarque, ozan, wstephenson, zekkerj |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Mandriva RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 4.6.2 | |
Sentry Crash Report: |
Description
Andrey Borzenkov
2011-03-08 14:19:08 UTC
// Add Gokcen to CC I confirm that this also happens on my machine. network-manager: 0.8.1+git.20101009t040337.01fa170-0ubuntu1~nmt1~lucid1 from http://ppa.launchpad.net/network-manager/trunk/ubuntu/ plasma-widget-networkmanagement: 0.9~svn1137272-0ubuntu2~lucid1~ppa1 from http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu/ OS: Kubuntu 10.04 64bits. The problem is a missing wirelessHardwareEnabledChanged signal emit in Solid' NetworkManager backend: https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/2ec6533494a23164ee9c2de4ab65d5fa372aff5c Without that emit Plasma NM is not able to recognise wireless rfkill state changes. The fix will be available in KDE SC 4.6.2 but unfortunately until then you will have to apply the fix to Solid manually. Git commit 591a85e2c62e10f2792517343f6fdd6316a933b6 by Lamarque V. Souza. Committed on 08/03/2011 at 22:31. Pushed by lvsouza into branch 'master'. Sanitize the Networking, Wireless and Wwan checkbox handling according to Dan Williams comments in http://mail.gnome.org/archives/networkmanager-list/2011-March/msg00063.html Quoting: Possibly. Here's what *might* be going on... usually GUI tools will hook a UI element like a checkbox up to a property so that the checkbox automatically updates when that property changes. In the case of the WiFi Enabled property, that's clearly the right thing to do as other tools besides the applet could toggle that property without the applet's knowledge, but the applet must still reflect the current state as provided by NetworkManager. But the applet must also respond to *user* initiated changes to that checkbox as well. Usually that happens when the applet attaches to the signal/slot that indicates the checkbox has been toggled, and upon receipt of that signal it tells NM to enable/disable wifi. But if the code also toggles the checkbox as a result of NM sending a property-changed signal, that could result in the NM change signal toggling the checkbox, which the applet interprets as the user clicking on the checkbox, which the applet then handles by telling NM to explicitly enable/disable wireless. Basically, the applet should never update NM's user wifi state based on signals from NM, or from NM's wifi hardware enabled state. Lamarque: although that is not the cause of the problem that started that mailing thread I think it is a good idea to avoid sending unneeded NM calls to change Networking, Wireless or Wwan state. I also added two KDE_IS_VERSION(4.6.2) #if's to really fix the problem for KDE SC < 4.6.2 users. CCBUG: 267967 M +50 -71 applet/nmpopup.cpp M +0 -4 applet/nmpopup.h http://commits.kde.org/networkmanagement/591a85e2c62e10f2792517343f6fdd6316a933b6 |