On Fri, 12 Dec 2008, Tony Vroon wrote:
> On Thu, 2008-12-11 at 17:47 -0200, Henrique de Moraes Holschuh
> wrote:
> > I don't think so if you mean Gnome knowing what to do with EV_SW
> > SW_RFKILL_ALL. That is not a report that radios got rfkilled, but
> > rather a COMMAND to rfkill all radios.
>
> Right, so are we talking across purposes here?
Probably. You still need to generate that SW_RFKILL_ALL input event
anyway, btw, so that the rest of rfkill can know when the user wants
all radios killed.
> I want to report radio status to userland so NetworkManager can stop
> helplessly flailing around asking me for a WPA2 password in a loop
> if I kill the radios.
That is a bug somewhere, and at first glance it looks to be either in
the wireless network driver, wpa_supplicant, or network manager. It
needs to be fixed, not worked around.
What is the WLAN driver involved? Is it rfkill-aware?
> What I have is an event-driven report that includes radio killswitch
> status, HARD_BLOCKED or UNBLOCKED in rfkill terminology. There is no
> SOFT_BLOCKED as I have no ability to turn individual radios on/off
> in software.
Whatever WLAN driver you use (which is not your Fujitsu Lifebook
platform driver) should just get complete rfkill support, and Network
Manager and wpa_supplicant have to do nonbraindamaged things when the
radio is rfkilled. So let's ignore it.
Just to make a point clear, you CAN ask HAL people to provide an OSD
notification keyed on uevents sent by rfkill-input. It is completely
correct to say "Radio kill switch active" and "Radio kill switch
inactive" from some uevents rfkill-input generates (or will generate,
I will check if I sent the patch already). It would still not mean
all devices have been rfkilled, but at least it shows the truth from
the point of view of the rfkill core and that has a higher chance of
being true than keying OSD on input events that nobody might be
listening to.
I hope the above takes care of the "I want user feedback when the
rfkill switch changes state" side. That leaves your question about
attaching rfkill classes to phantom BT and WWAN devices inside your
platform driver.
BT and WWAN rfkilling are basically implemented in two possible ways,
AFAIK:
WARNING: THE STUFF BELOW IS FOR PLATFORM DRIVERS, NOT NETWORK DEVICE
DRIVERS. NETWORK DEVICE DRIVERS DO IT SLIGHTLY DIFFERENT.
1. rfkill actualy is/looks like a hotplug/hotunplug operation
1a. You can do it at will (or you can do it at will except when the
hardware switch is enforcing that they remain rfkilled):
Attach rfkill classes to platform devices if you know this is
the best way to software-command this functionality.
Most notebooks go here for Bluetooth and WWAN. It is a pity
Fujitsu Lifebooks don't.
1b. You cannot do it at will
Attaching it to the rfkill core simply is not supported, and
even if you force the issue with a weird toggle_radio(), you'd
end up with a device that causes annoying behaviour every time
you want to change its rfkill state. So, I cannot recommend
it.
The user knows if the radios are around or not from whatever
hotplug subsystem they are tied to (PCI, USB), and that's what
should be issuing events the user can see (only they will be of
the "hardware connected/disconnected" sort, and not of the
"radio killed" sort.
2. rfkill doesn't mess with the device existence, it just disables
energy output:
2a. You can do it at will (or you can do it at will except when the
hardware switch is enforcing that they remain rfkilled):
You attach it to the rfkill core using a rfkill class, unless
there is a better place to do it. Usually, there isn't.
This is rare, as BT and WWAN are usually of type 1a, and WLAN
is usually of type 2b.
2b. You cannot do it at will
The rfkill class is to be attached to the device driver for that
device, i.e. something in the bluetooth subsystem, USB subsystem
or a wireless network driver.
> Should I be creating individual Bluetooth/WLAN/WWAN rfkills that flip
> between HARD_BLOCKED & UNBLOCKED with force status and return failure
> for a radio state change attempt?
Like I said, that's probably quite not nice for the user, and might
cause very annoying behaviour on userspace applications. The rfkill
core won't care for it either, but it won't break.
However do NOT do it for WLAN. Almost every WLAN device knows quite
well if it is being rfkilled or not by a hardware rfkill line, and it
is their business to report it. And the wireless network drivers are
being ported to connect to the rfkill core.
> But perhaps code talks, let me just attach what I have right now. Both
Not really in this case, no. It is not a case of coding it right,
after all... I will look over the input device stuff in a separate
reply.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
