On Tue, 22 May 2007, Dmitry Torokhov wrote: > > It was beaten into my heads that rfkill has two parts and that one is not to > > try to use one without the other: The sysfs class, and the input layer > > stuff. > > I am sorry if I come out too strong sometimes. No problem, I am sure I come out too strong quite often, as well. > > And I was TOLD I cannot even look at rfkill sysfs support without taking > > rfkill-input into the picture. Which is a dubious design decision IMHO, but > > I am quite willing to go with it. > > Not the rfkill-input but input device piece. rfkill-input is an > optional glue that may not be needed is userspace is willing to do > full control. I see. I didn't understand what you meant correctly. I do, now. > > 1. a get_radio_state() hook, that gets called when rfkill needs the state. > > I sent a patch implementing it, with 100% backwards compatibility for > > drivers that don't want to implement get_radio_state(). > > > > 2. a set_radio_state() method in the class, to change the radio state > > without causing a loop through the underlying driver. I understand a patch > > for this is not needed, but it would take about 10 minutes to write one and > > QA it, and I will do so if anyone asks for it. > > OK, so let's say we have that call. An user pushes the button and you > disable the radio. Now, imagine you have a laptop with a button that > does not directly control radio state, i.e. the driver needs to > explicitely turn the radio off when it detects button press. And the If the user pushes the button and thinkpad-acpi disables the radio, it will **only** be because something (rfkill-input, userspace writing to rfkill sysfs, or using one of the other thinkpad-acpi interfaces, which I will translate into a rfkill toggle_radio to keep things in sync -- and it is rfkill's problem to give me an interface that does the right thing re. any user locks it has) told thinkpad-acpi to when that something noticed the button was pressed. So far so good. > user who was tired of hittign the button by mistake and turning off > his radio decided to ignore the button. He wrote into "user_claim" > sysfs attribute and thought that that's it. But it would not work It looks to me like it will work just fine, *as long as* the button is going through rfkill, which is the case. > because the driver was way too optimized and smart and decided to go > around rfkill and current system policy and trun the radio off > directly. In the absence of bugs, the driver won't turn the radio on/off directly "because it wanted to". It will do so because: 1. rfkill told it to (no problem here) 2. another side path to the DRIVER told it to, and usually this means a legacy sysfs interface or /proc interface, so it implies userland action. In this case, there is no reason why it should not go through rfkill. Just tell me what method to call that will do the right thing, and I will use it. But what if the user pushes the button and the radio gets disabled without going through rfkill? We are taling about a non buggy system here, so that happened because the user pushed a button or moved a slider switch that kills the radio off *in firmware or in hardware*. The driver did not decide to turn the radio off, or to keep it off, or whatever. Neither thinkpad-acpi nor rfkill took any action to disable the radios, but they still got turned off anyway. And it is anyone's guess if it is something the driver can override back to the "rfkill desired state". In thinkpads *both* can happen (yes, it is that bad): 1. If the user did not tell thinkpad-acpi to override the radio-kill hotkey (note, thinkpad-acpi does NOT KNOW which of the hotkeys that is! it can change from model to model, although fn+f5 is the most common), or if it is a X60 that just ignores what thinkpad-acpi tells it to do anyway, the firmware will toggle the radios on/off in a way that thinkpad-acpi *can change*. 2. If the user actually has a hardware slider switch in his thinkpad and moves that from "on" to "off", the hardare kills all radios, and you cannot override that in any way. 3. If the user actually has a hardware slider switch in his thinkpad and moves that from "off" to "on", I have no idea of what the firmware will do. It does remove the "keep radios off" override, but it might also restore all radios to their desired state, or switch them all to "on". So, the radio state after an "off" to "on" hardware slider switch change is undefined, you have to query the radio to know. > I understand that some switches are wired diretcly to radio and can't > be overriden but we need to look at bigger picture. Well, I am trying to get those switches that are wired directly to the radios to work sanely with rfkill, instead of confusing it. All thinkpad physical radio kill slider switches are like that, as it is required by law in some countries for stuff that goes on board of airplanes, etc. The BIOS radio-kill option also works like the physical radio kill slider, but requires that one reboots and go into the BIOS setup screen to change its state. The fact that almost all thinkpads also have a firmware-driven hotkey that can toggle radio state behind a driver's back is just icing in the mudcake. So, in the end thinkpads have at least one of *three* possible radio kill "input devices", and it is usuall to have more than just one of them: 1. A BIOS option that requires one to enter the BIOS setup screen to change (i.e. a reboot). Hardware "off" override: if it disables the radios, it cannot be overriden. I have no idea if we can detect this switch state directly, or even if we need to. 2. A physical slider switch that makes sure in hardware that the radios are off, and can have side-effects when changed to the "on" position. Windows usercase is to turn radios ON, so that is a strong hint of how it should be used. Hardware "off" override: if it disables the radios, it cannot be overriden. 3. A hot key (i.e. button) that may or may not be under control of thinkpad-acpi (and it is not by default!). If it is NOT under control of thinkpad-acpi, it may do nothing, or it may toggle the radios through firmware. If it is under control of thinkpad-acpi, it might still switch the radios on/off through firmware in a X60 (this is probably a bug somewhere). It is not a hardware override, thinkpad-acpi can toggle the radios too. -- "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 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
