Open timgreen opened 1 year ago
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
pkexe ls
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:
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: af0115eb0cbd927a6ba21f5865d9e8489556db22
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 af0115eb0cbd927a6ba21f5865d9e8489556db22.
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 https://github.com/waycrate/swhkd/commit/af0115eb0cbd927a6ba21f5865d9e8489556db22 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:
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.
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:
rfkill_epo
('emergency power off').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.
Version Information:
uname -a
)Debian 5.18.16
swhkd -V
)swhkd 1.2.1
Describe the bug:
pkexec swhkd
turn off the wifi on start. I have to enable it manually after.Note
Expected behavior: Don't turn off wifi
Actual behavior:
To Reproduce: Just run
pkexec swhkd
Additional information: Anything else you'd like us to know ?
Happy to grab other logs to happy debugging.