Hi Tim, I'm not entirely sure why this happens but I've faced this issue too. Are we sure this isn't an issue with networkmanager / pkexec to begin with?

From limited tests, I believe it is caused by swhkd.

Things I observed

• pkexec other commands didn't turn off wifi. e.g. pkexe ls
• pkexec swhkd with a invalid config didn't turn off wifi
• pkexec swhkd while another swhkd is already running didn't turn off wifi

So the issue is likely in swhkd after performing config validation & other sanity checks.

I am unable to reproduce this issue on my side, so this will mostly be guess work.

I think there are three things which could create problems:

1. uinput device creation: not very likely
2. swhkd grabbing a wifi switch and messing with it: looking at the logs, this does not seem to be the case
3. the evdev library doing something weird in the background: this seems plausible

I don't think 1) could really be the cause, and if it is, I am unsure how we could solve that.
You could test 2) by adding --device 'AT Translated Set 2 keyboard' to the pkexec swhkd call.
For 3), we talk about this issue in #172, but given it appeared only after an update to evdev for @TTWNO, I don't think the library is the issue.

@Shinyzenith If you have any idea about how to reproduce this, please let me know, so I can run tests on my side.

I managed to reproduce this on my end, I will investigate.

This was introduced in commit: af0115e

I will check if we can make this work or if we just revert the commit for now

This was introduced in commit: af0115e

I will check if we can make this work or if we just revert the commit for now

I faced this issue multiple times before inclusion of that commit. My machine has the latest stable tag, not main branch.

It's probably something else. I've tried reproducing it but it's really a hit or miss.

I will try to run this again, but on my side it seemed to not happen before this commit, and then to happen every time swhkd is launched after this commit.

I tested it this way:
Run rfkill list to check if any of your devices are soft blocked. If there are, just run rfkill unblock <id>.
On the latest version, as soon as I launch swhkd rfkill list shows my devices as soft blocked. On 1.2.0, it does not happen (or if it does, it's not always). I just run git bisect main 1.2.0 and ran the rfkill test for each bisect commit. It gave me af0115e.

I will try to create an automated rfkill test and run swhkd multiple times before this commit to check if it happens.

I can reproduce this on my machine. I don't use NetworkManager as part of my setup if this is relevant.

I also confirm this, previous commit to af0115e works well.

Okay I see. @ajanon Should I get in touch with upstream and mention that switch features are interfering with rfkill?

I am working on this.
The issue is that the kernel expects the rfkill value bit (SW_RFKILL_ALL) to be set to not block everything. (See below for the detailed explanation)

I can see some ways out of this from our side:

• drop switch support completely: not ideal, since it would be a cool feature to support
• drop rfkill switch support: this is the easiest to implement without losing too much
• emit an event on the virtual device to set the rfkill value bit and unblock radio devices.

Emitting an event kinda works: it unblocks all devices. This might be an issue, though, as this unblocks devices regardless of their previous state: if a user was blocking a device, this will unblock it. We cannot do anything about this, as the default rfkill mode is to unblock everything, not to restore the previous state. In addition, there will be a gap between the block and the unblock calls: the user's devices will be off for a while.

Kernel rfkill explanation

The rfkill subsystem registers a handler to listen for device events. This handler is called when a new device is added to the system, either from a virtual uinput device or from a physical device.

The handler then calls rfkill_connect which in turns calls rfkill_start. This tests if the SW_RFKILL_ALL capability bit is set on the device (which just informs if the device supports that switch or not) and act upon the switch value:

• If the value bit is unset, it will default to rfkill_epo ('emergency power off').
• If the value bit is set, it will instead use the default master mode which is to unblock all.

There is no way to set the default mode per device—it is set globally when the module is initialized.

Emitting an event to the virtual device also calls the default mode. Furthermore, the epo call gets processed with (close to) no delay, whereas the unblock call will only get processed after at least 200ms (RFKILL_OPS_DELAY) after the previous call (which is most certainly the epo call in our case).

There is also no way in the current uinput kernel API to set switch values at device creation (sw long in the input device struct). The epo from rfkill is unavoidable for now.

Just to make this clear: the evdev crate developers cannot do much about this, as the problem lies in the kernel.

I will search through the kernel mailing lists to see if somebody already reported this kind of difficulty.

In the end, I found a better way! (see #180)

@ajanon thank you so much for the detailed report, I finally understand the issue completely. You have my gratitude.

I believe I am still having this happen greater than 50% of the time latest main commit (swhks/d 1.3.0-dev).

❯ rfkill list
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no

@ NeutralAlice is correct, this is still a recurring issue. I believe it might be due to a race condition? Maybe we should consider dropping rfkill support alltogether? @ajanon

I confirm this regression in 1.3.0-dev

what should we do to avoid this issue?

what should we do to avoid this issue?

The best way would be to remove rfkill support completely. We still don't know the root cause of this regression.