Hi Oldřich, > > Ah. So I guess when hci0 gets registered, the acer rfkill state hasn't > > been updated yet, hence registering hci0 as blocked. > > No, that is not the case. I can play with `rfkill list` immediately after I > press the HW bluetooth switch and show that hci0 is not there (still > unregistered) while acer-bluetooth is already "unblocked" - I've tried to run > `rfkill list` repeatedly manually from console immediately after I pressed > the > HW BT switch and acer-bluetooth was "unblocked" several runs while the hci0 > wasn't there. When hci0 appeared, it was "blocked". > > As I wrote, I didn't find anything changing the global state, which is > actually > used to "block" the newly appearing hci0 (in the rfkill_sync_work method). It > looks like the global state is just "blocked" forever - and it is "blocked" > as > a side-effect of the call to rfkill_init_sw_state (changes permanent=true) > and > then call to rfkill_register from the acer-wmi driver. I can verify this in > the following days (that the global state stays the same all the time).
Well the global state would be changed by the KEY_BLUETOOTH input event. But like I said, it's tricky in this case because multiple events come from the same event source and race against each other. johannes -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
