On Fri, 06 Jun 2008, Dan Williams wrote: > Let me explain this a bit more. > > - My original request was based on my flawed understanding of the > current scope of the rfkill system Ok. I am keeping that in mind. > - If the rfkill system is _only_ supposed to handle switches that turn > the radio off automatically, then a "third state" for the rfkill class > really serves _no_ purpose at all, because the radio's already blocked > when the switch is thrown Given these rules (not documented fully yet, I shall fix it when this thread quiesces): 1. Every transmitter shall have ONE, and just ONE (not zero, not two, not more) rfkill class attached. For those transmitters lacking support in hardware to make it block, the drivers shall quiesce them and avoid doing anything to cause transmissions, or even use bus tricks to power the device down (i.e. the driver will emulate a switch capable of doing the blocking). Thus, rfkill class will give you the DEVICE (radio) rfkill block/unblock state on wireless devices (ignore switches for now, I will explain them in another email). The information of whether a transmitter is currently blocked in a way you can request it to be unblocked (soft-kill) or currently blocked in a way you cannot request it to be unblocked (hard-kill) DOES belong in rfkill class. Do you want/need that information, yes or no? > - There are drivers that implement rfkill (laptop-specific BIOS drivers) > that have _no_ associated transmitter device; thus the current 'struct > rfkill' can only be a representation of the _switch_; thus a "third > state" would be useless here as well (as is the toggle_radio() callback) I haven't finished replying to your other email yet, because it is not a fast reply (and I am in a hurry in the next two days) and I need to look at hp-wmi itself to understand what the issue that is causing confusion is. THAT reply will explain to you how it works with "pure read/write switches that are not in a wireless device". THEN we shall be able to unravel the confusion, and I will finally understand what you are trying to tell me (or you will understand what I am trying to tell you). > - It just seems a lot clearer to me to have a separation between the > rfkill switch and the radio bits since there's no need to tie them > together And this is part of the confusion. So, for now, please just look at the question four paragraphs above, and tell me whether you want that information or not. I'd think you would, since you want to gray out the "enable radio" button when the radio is blocked by some hardware signal you cannot override, but I could be confused about it... -- "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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
