adding linux-wireless@xxxxxxxxxxxxxxx i expect somebody there may know a thing or two about the proper way to do rfkill... -- Len Brown, Intel Open Source Technology Center On Fri, 12 Dec 2008, Henrique de Moraes Holschuh wrote: > 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 > -- 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
