On Tue, 08 Jul 2008, Andy Lutomirski wrote: > I'm still a bit confused. > > Suppose I have a laptop with a physical switch marked "radio" which > tells the OS which position it's in *and does nothing else* (via ACPI or > whatever) and a radio which has a (pure) software rfkill controller. > Suppose further that this laptop has a radio button as well. Is that a hot key that also does nothing else but sit there and report "I have been pressed" ? I will assume so in the rest of this reply. > This would look exactly like my Thinkpad X61s, except that the rfkill > switch would be connected to the rfkill controller in software, not > hardware. > > I think it would have the exact same problem and the fourth state > wouldn't help because it would never be any variety of HARD_BLOCKED. Correct. The fourth state doesn't help with ANY problem I know of (I thought it could help in sleep/resume, but I found out that I can't use it because not every driver will be able to implement double-blocking, even if it has a hardware rfkill line). The fourth state ends up being just more information for the user. What would happen in the scenario that you describe is this: the switch will command rfkill-input. The key will ALSO command rfkill-input. So it will override the switch, which I agree is not the best way to deal with it, to put it lightly. This is a problem in rfkill-input, and I suppose we should fix it. Basically, rfkill-input will have to find out, and keep track of the input device switches (the information is there, but it will add some complexity), and not let other events override them. It can't just keep track of changes caused by switches, because you need to query the switches about their initial state to do it right (and that's another bug in current rfkill-input). More stuff for the TODO. Argh. -- "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
