Hi Johaness, Just a small correction. On Monday 21 March 2011 15:35:35 Johannes Berg wrote: > Hi, > > > > > It maybe workaround another rfkill-input issue, but causes it > > > > replicate acer-wmi's bluetooth killswitch initial state (or any > > > > driver that used rfkill_init_sw_state) to any new bluetooth > > > > killswitch. > > > > > > > > It's not make sense. > > > > > > I think the reason is that rfkill-input only has a global concept of > > > per-device states. The alternative would be to force a newly registered > > > rfkill device to the state that was set by rfkill-input. > > > > Yes > > I don't know if that works though. Does it make more sense? I'm not > sure. Why bother with "persistent" then anyway? I think the logic as we > had it was meant to make things follow the persistent state you had > before you shut down and that was saved in the BIOS or whatever. > > > > Is it possible that acer-wmi reports both a hotkey event _and_ an > > > rfkill event? > > > > Emit needlessly KEY_BLUETOOTH when acer-wmi initial may not a good idea > > if there have any userland daemon to listen the keycode. > > > > I am trying to remove rfkill_init_sw_state then workaround this issue > > in .set_block by maintain a driver initial flag in acer-wmi. > > No I mean ... it seems that the BIOS reports both a hotkey and an rfkill > event. Could those be clashing? > > It seems that what happens is roughly this: > 1) at boot, all BT is set to soft-killed due to the way the BIOS > started up > 2) when you press the button, it's a toggle, so rfkill-input toggles > all BT rfkill instances (acer and hci0) > 3) now acer _also_ reports, via rfkill_set_sw_state(), that the acer BT > rfkill instance is not soft-blocked > > Then again, even that should work fine? Clearly I don't understand the > issue yet. hci0 doesn't exist when the BT switch is off. The hci0 device and rfkill switch appears when you unblock SW rfkill or by pressing the HW switch. It disappears when you block the switch again. hci0 is set to "blocked" when it appears, because the acer-wmi driver have registered acpi-bluetooth rfkill switch during boot, which was set to "blocked" initially with a call to rfkill_init_sw_state. So what happens actually is this: 1) at boot, BIOS says the bluetooth is disabled, so the not-registered state of acer-bluetooth rfkill is set to "blocked" (rfkill_init_sw_state, sets the "persistent" bit). The acer-bluetooth is then registered, which forces the global bluetooth state to go "blocked". No hci0 exists at this time. 2) when you press the button, hci0 appears and the rfkill is set to the global bluetooth state (in rfkill_sync_work), which is "blocked". >From my understanding acer-wmi reports the change via acer_rfkill_update work (executed every second). It just calls rfkill_set_sw_state, but that doesn't update the global state. I don't know at which time that happens, but generally I didn't find anything that could eventually enable hci0 state or global state to "unblocked". Cheers, OldÅich. > > > Does it possible we add this rfkill module option for user can control > > disable rfkill-input when rfkill driver probed? > > > > Because, distro was shipped with different company's machine, like: Acer > > or MSI, different machines almost have different wifi/bluetooth/wwan key > > use case. > > Well, I don't think we should require a config to work "out of the box", > so I'm not sure that makes sense. > > > Sometimes, we want to use rfkill-input, but sometimes we have userland > > GUI application to provide rfkill control panel to end user. We already > > used urfkill daemon to disable rfkill-input by ioctl way, but like this > > issue, it was happen on driver probe. > > Yeah but when urfkill starts up, it could just force the status it > thinks things have. Since it can simply override the current status > there doesn't seem to be a need for disabling the logic first. > > Still though I don't understand how we arrive at the issue at all. > > OldÅich, can you run "rfkill event" while you press the button with a > stock kernel that shows the problem and no patches? > > johannes > > > -- > 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
