hid/hsctrl: Add support for Wireless Radio Button

[git_danielschaefer.me]

Summary

Implemented for example on Framework Laptops as the Airplane Mode button.

Sponsored by: Framework Computer Inc

Test Plan

build tested and manual tested on top of stable/15

[obiwac]

i confirm I saw this work on his machine

[0mp]

I saw it being built and manually tested.

[obiwac]

Can confirm this works on my machine too! Although sometimes when I press the button fast enough, it doesn't register. It always does when I hold it down for more than a fraction of a second though. Assuming this will be fixed once we're able to pass GPIO interrupts to iichid.

for reference: https://www.usb.org/sites/default/files/hutrr40radiohidusagesfinal_0.pdf

btw, only tangentially related, but see D55265 for a bit of discussion on what a generic rfkill interface would look like on freebsd

sys/dev/hid/hid.h

108–109

not a big deal but I think it would be clearer if this was named RFKILL control/button instead of generic "radio control"

sys/dev/hid/hsctrl.c

78–84

nit but I feel like this comment would make more sense above the

		evdev_push_key(evdev, KEY_RFKILL, 1);
		evdev_push_key(evdev, KEY_RFKILL, 0);

100

assuming this is being done so that we don't send rfkill up/down twice if we somehow got 1 twice in a row?

[git_danielschaefer.me]

sys/dev/hid/hid.h

108–109

But this is what they're called in the HUT spec you linked above

sys/dev/hid/hsctrl.c

100

Yep

[wulf]

This comment was removed by wulf.

[wulf]

Radio button can not be correctly handled with hidmap. MS does strange things here assuming every event in report as a keypress. E.g. ASUS TUF always reported radio key as depressed that brokes Linux but works on Windows

[obiwac]

In D56026#1281776, @wulf wrote:

Radio button can not be correctly handled with hidmap. MS does strange things here assuming every event in report as a keypress. E.g. ASUS TUF always reported radio key as depressed that brokes Linux but works on Windows

this revision does exactly what i think you're describing. Would you have liked it to be done some way else?

sys/dev/hid/hid.h

108–109

well actually it calls it "wireless radio". but I'm fine with how it is now

[emaste]

I've applied this to my local tree for testing

[bz]

Forgive my ignorance but what exactly is this doing from a high level perspective not from the functional change about simulating the key press.
If I had to try: it takes the key press from the function button and sends a simulated key press to evdev from whatever X thingy to consume?

But what triggers the actual RFKILL hardware level disconnect? The same button press?

And can software (e.g., a widget) undo this or does one have to press the button again?

I am just trying to puzzle software rfkill and hardware rfkill states together and am trying to understand where this fits in...

[obiwac]

But what triggers the actual RFKILL hardware level disconnect? The same button press?

Nothing at the moment. we need a generic rfkill interface on freebsd; see D55265 for a little discussion on this

And can software (e.g., a widget) undo this or does one have to press the button again?

That's I think the end goal. Pressing this button just reports this to the desktop environment or some other user program, and it is responsible for actually rfkill'ing or not.

[bz]

In D56026#1325514, @obiwac wrote:

But what triggers the actual RFKILL hardware level disconnect? The same button press?

Nothing at the moment. we need a generic rfkill interface on freebsd; see D55265 for a little discussion on this

And can software (e.g., a widget) undo this or does one have to press the button again?

That's I think the end goal. Pressing this button just reports this to the desktop environment or some other user program, and it is responsible for actually rfkill'ing or not.

That highly depends ... software can clear software, hardware can clear "hardware".

And that's why I asked. If I press the button on my non-framework laptop, the BT USB device just vanishes (you can see on console) and wifi stops transmitting as it's firmware/hardware doing that (and the wifi driver getting an interrupt I believe even on that one too).

So yes, we need a proper framework that deals with software and hardware rfkill in a way that can hook into drivers. net80211 has no clue about it; LinuxKPI has some already (surprise; given structures etc. are there in the drivers) but we don't drive it or use it in any way.

[obiwac]

And that's why I asked. If I press the button on my non-framework laptop, the BT USB device just vanishes (you can see on console) and wifi stops transmitting as it's firmware/hardware doing that (and the wifi driver getting an interrupt I believe even on that one too).

yeah, as you say for devices with hw rfkill buttons we indeed want a way to report this to the user. The framework button is purely a software things afaiu