Airplane mode gets turned on and stuck after sleep mode

Question

I am using Ubuntu 18.04 LTS dual booted with Windows 7 on HP Envy 15. After my laptop goes into sleep mode (lid closed) it will turn on airplane mode but the button to turn it off is greyed out and says "use hardware switch to turn off" and the only other switch is the Fn+F12 which doesn't work. It fixes itself on reboot but I was wondering if there was a way to prevent it. In Windows, it happens plugged in and on battery. Before sleep:

$ sudo rfkill
ID TYPE      DEVICE      SOFT      HARD
 0 bluetooth hci0   unblocked unblocked
 1 wlan      phy0   unblocked unblocked

After sleep:

$ sudo rfkill
ID TYPE      DEVICE      SOFT      HARD
 1 wlan      phy0   unblocked   blocked

I have tried blocking and unblocking it via rfkill but it doesn't work the only way that I have found to disable it is via rebooting.

Answer 1

EDIT: This solution has been superseded by a fix for the actual, root issue I found. Please disregard the following information

TL;DR: https://github.com/snyball/hawck. Use this tool to remap keycode 255 to a null character and the problem's solved.

The issue here is that whatever driver Linux uses for the lid/tablet mode switches erroneously interprets them as generating Keycode 255 (or 247, depending on... stuff. I never quite figured out why it's sometimes one or the other). Keyvode 255 happens to be the rfkill key, which puts the system into airplane mode.

It took me so. freaking. long. to fix this. I tried messing with DKMS, I tried using Xmodmap (which actually worked for awhile, until I realized X11 was messing with my touchpad), I ran a program in the background that constantly ran rfkill unblock all, and I even tried disabling the keycode at the kernel level. What finally worked? A free and open source program called Hawck.

Hawck (https://github.com/snyball/hawck) is by far the best solution for this issue, at least until whatever malfunctioning kernel driver is updated. It's desktop-agnostic (heck, it even works in console mode), it's designed to be run on startup, and unlike Xmodmap it's modular and scriptable. What I did was I created a script called "fixapmode.hwk" (the name doesn't matter), with the following contents:

key(255) => insert ""

(If you replicate my method, please keep in mind there is NO SPACE between the quotation marks).

I then set the script as executable, enabled it in Hawck, set Hawck to run on startup, and it worked! The only lingering issue was that my laptop would still start in Airplane mode, since Hawck didn't immediately kick in on boot. I solved that issue by making a new startup program with the command rfkill unblock all. With that, I can say that the problem is completely fixed. The only annoying thing is that the first time you login from boot, you'll get a notification from Hawck letting you know it loaded your script successfully. However, there's probably a way to turn this off, and it's much much better than the alternative.

Hope this helps. Cheers!

Answer 2

After sleep try to execute these commands:

sudo systemctl restart network-manager.service 
sudo ifconfig wlx8c882b131d8 up
sudo rfkill unblock all

Change wlx8c882b131d8 to the name of your own WiFi adapter. If this works, than you can create a systemd service that will start after you wake from sleep mode, and execute the above automatically.

Also, in some cases, battery removing/inserting works.

Additionally, does the key combination that enables/disables your WiFi work in case of using it on unblocked device? If no, than find out why.

And, as nobody suggested (reference)

gsettings list-recursively | less

You'll find the entry about Airplane Mode by typing /rfkill. Copy that line and use it on a new command line with the gsettings "set" parameter, but change the "true" to "false":

gsettings set org.gnome.settings-daemon.plugins.rfkill active false

However, the previously suggested command has its own cons. So you could try the next suggested solution taken from the same reference:

I had the same problem on my HP 250 G5. For me it was caused by the lid sending scancodes e058/e057 on lid close/open.

For some reason GNOME decided this corresponded to Airplane Mode On. As ropid mentioned you can fix it by disabling GNOME's rfkill plugin, but this also prevents enabling/disabling bluetooth via GNOME settings.

I managed to fix this on my by mapping e058/e057 to keycode 245 (Display Off)

Use { journalctl -f } before closing and opening your lid to find out if closing the lid simulates any key presses. The journal entry should also tell you the scan code of the key press (e058 & e057 in my case)

Then use { setkeycodes [SCANCODE] [KEYCODE] } to map the scancode sent by the lid to a desired key (in my case I used setkeycodes e058 245 e057 245). If you don't want to map it to DISPLAY OFF you can find a list of other keycodes in /usr/include/linux/input-event-codes.h

If the problem is fixed make it persistent by creating and enabling a systemd unit file in /etc/systemd/system/ The file I use looks like this:

[Unit]
Description=Fix WiFi off on lid close
[Service]
ExecStart=/usr/bin/setkeycodes e058 245 e057 245
[Install]
WantedBy=multi-user.target

Answer 3

This is a bug in the Intel HID driver in the Linux kernel. To fix:

• Download the Linux kernel source

• Open the file drivers/platform/x86/intel/hid.c in a text editor

• Do a search for the string "KEY_RFKILL". It should find a line that looks like the following:

  { KE_KEY, 8, { KEY_RFKILL } },

• Delete the string "KEY_RFKILL". The line should now look like this:

  { KE_KEY, 8, { } },

• Compile and install the kernel, it should no longer turn on airplane mode when you close the laptop/put it in tablet mode.

Cheers!

Edit: Since this is an issue with Intel's HID implementation, it means that this error may not exist on AMD models. Can someone with an AMD machine confirm this?