GNOME Bugzilla – Bug 788683
rfkill switch stops working after logging in into Gnome session
Last modified: 2018-04-18 16:42:13 UTC
rfkill switch (laptop button) works in both console and GDM login screen but stops working once logged in into Gnome session. Hardware: Intel Core i3-3227U CPU, Intel Ivybridge Mobile, WiFi: integrated, Atheros AR9485. These lines are logged during system startup: NetworkManager[431]: <info> [1507401827.7340] rfkill0: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.0/0000:07:00.0/ NetworkManager[431]: <info> [1507401827.7342] manager[0x5603e2fe3100]: rfkill: WiFi hardware radio set enabled NetworkManager[431]: <info> [1507401827.7342] manager[0x5603e2fe3100]: rfkill: WWAN hardware radio set enabled ... NetworkManager[431]: <info> [1507401831.7092] manager: rfkill: WiFi enabled by radio killswitch; enabled by state file gdm[466]: GdmSession: Handling new connection from worker NetworkManager[431]: <info> [1507401831.7094] manager: rfkill: WWAN enabled by radio killswitch; enabled by state file gdm[466]: GdmSession: Authenticating new connection Then these lines show up after logging in: gsd-rfkill[1120]: g_object_notify: object class 'CcRfkillGlib' has no property named 'kernel-noinput' kernel: rfkill: input handler disabled Might be related to Bug 788463, the difference is it's not about any hot-pluggable dongle.
(In reply to Stanislav from comment #0) > Then these lines show up after logging in: > gsd-rfkill[1120]: g_object_notify: object class 'CcRfkillGlib' has no > property named 'kernel-noinput' > kernel: rfkill: input handler disabled I am seeing the same warning, but not the bug. The hardware rfkill switch works fine for me. Intel Core i5-2450M with Intel 6230 wifi chipset.
The warning is entirely harmless and has been fixed in the meantime. Quick explanation of what is happening. For years, we had the issue that GNOME and the Kernel were both handling the rfkill switch events. This resulted in it e.g. being impossible to disable airplane mode because the kernel would disable it and then GNOME would re-enable it for the same button press. The solution is to disable the in-kernel rfkill handling while the GNOME session is active. Now, the issue you are seeing is that the event is not handled by gnome-settings-daemon even though it should be. Could you please include the following information: 1. What is the exact laptop model? 2. Could you attach the evemu-describe output for your laptop specific hardware? Feel free to simply run the following one liner as root and attach the output here: # for i in /dev/input/event*; do evemu-describe $i; done
Created attachment 371085 [details] output of evemu-describe for HP Pavilion TS Sleekbook 15/18FD Thank you for your comment! It brings more clarity about rfkill behavior. My laptop is: Hewlett-Packard HP Pavilion TS Sleekbook 15/18FD, BIOS F.1B 08/13/201
Created attachment 371087 [details] output of evemu-describe for Dell Inc. Inspiron 5770/0XH3XD, BIOS 1.0.4 09/08/2017 Just made a check for another laptop - Dell Inspiron 5700: it has the same issue: rfkill button works in console/gdm screen but doesn't work in Gnome (X11) session; every time I press it I just see this system log message: kernel: dell_wmi: Unknown key with type 0x0010 and code 0xe008 pressed
Hi Benjamin, (In reply to Benjamin Berg from comment #2) > The warning is entirely harmless and has been fixed in the meantime. > > Quick explanation of what is happening. > > For years, we had the issue that GNOME and the Kernel were both handling the > rfkill switch events. This resulted in it e.g. being impossible to disable > airplane mode because the kernel would disable it and then GNOME would > re-enable it for the same button press. Can I ask what's the reason behind letting GNOME to handle rfkill at first place? For consistency, either kernel or user-space can handle rfkill hotkey exclusively. Turning rfkill control off via IOCTL is a rather surprising behavior.
(In reply to Stanislav from comment #4) > Created attachment 371087 [details] > output of evemu-describe for Dell Inc. Inspiron 5770/0XH3XD, BIOS 1.0.4 > 09/08/2017 > > Just made a check for another laptop - Dell Inspiron 5700: it has the same > issue: rfkill button works in console/gdm screen but doesn't work in Gnome > (X11) session; every time I press it I just see this system log message: > > kernel: dell_wmi: Unknown key with type 0x0010 and code 0xe008 pressed It's a red herring, I'll send a kernel patch to let dell-kmi.ko to ignore the hotkey. You'll see similar messages when you press Fn+ESC to switch Function/Multimedia mode.
(In reply to Kai-Heng Feng from comment #5) > Can I ask what's the reason behind letting GNOME to handle rfkill at first > place? For usability reason we need to show an OSD. We cannot properly do so without also controlling the state. > For consistency, either kernel or user-space can handle rfkill hotkey > exclusively. Exactly, this is why the in-kernel handling is disabled when GNOME is handling rfkill events. The bug here is simply that we seem to be missing some rfkill related event that the kernel would be handling fine. Quite likely it is a straight forward fix, but I need to look at that carefully to check that everything is in place in the stack.
(In reply to Benjamin Berg from comment #7) > (In reply to Kai-Heng Feng from comment #5) > > Can I ask what's the reason behind letting GNOME to handle rfkill at first > > place? > > For usability reason we need to show an OSD. We cannot properly do so > without also controlling the state. Can you share more technical detail about this? The WiFi status icon always updates with correct rfkill status. So I guess OSD should be the same... > > > For consistency, either kernel or user-space can handle rfkill hotkey > > exclusively. > > Exactly, this is why the in-kernel handling is disabled when GNOME is > handling rfkill events. The bug here is simply that we seem to be missing > some rfkill related event that the kernel would be handling fine. Quite > likely it is a straight forward fix, but I need to look at that carefully to > check that everything is in place in the stack. Thanks for your explanation. At least on Dell systems, I can see key event from AT keyboard when wireless hotkey gets pressed. What is missing here is to map the event to "wlan"event, so an additional hwdb entry should do it. I just need to make sure I understand this issue correctly.
Well, that one is actually an easy fix. All you will need to do is update xkeyboard-config to a newer version, so that the KEY_RFKILL is mapped to "XF86RFKill". The code in gnome-settings-daemon is already in place. The upstream bug in question was: https://bugs.freedesktop.org/show_bug.cgi?id=100970 Both models should simply start working once xkeyboard-config is updated.
(In reply to Kai-Heng Feng from comment #8) Thanks for your explanation. At least on Dell systems, I can see key event > from AT keyboard when wireless hotkey gets pressed. What is missing here is > to map the event to "wlan"event, so an additional hwdb entry should do it. I > just need to make sure I understand this issue correctly. Yeah, a further entry mapping RFKILL to WLAN would also work. Though with the xkeyboard-config change we don't really need the re-mapping in udev anymore.
Closing as not GNOME as an xkeyboard-config update will fix it and there are other non-GNOME workarounds.