Hi Joey Lee, On Friday 25 March 2011 09:13:20 Joey Lee wrote: > Hi OldÅich, > > Per our log. > It's a interesting and weird situation. > > Your log subvert my assumption, the BT HW key only emit one > KEY_BLUETOOTH from ec but not from acer-wmi. > > æ åï2011-03-24 æ 22:34 +0100ïOldÅich JedliÄka æåï > > > Hi Joey Lee, > > > > I've done some experiments, here are the results. > > > > On Thursday 24 March 2011 14:13:29 Joey Lee wrote: > > > Hi OldÅich, > > > > > > Sorry bother you again, but after discuss with Johannes, he remind me > > > one import thing: maybe your BT HW key emit scancode and wmi event at > > > the same time. > > > > > > æ åï2011-03-24 æ 09:36 +0100ïJohannes Berg æåï > > > > > > > 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 > > > > > > My Acer TravelMate 8572 is commercial notebook, it only emit wmi event > > > when press wifi key. But, as I remember, there have some acer consumer > > > notebook emit both scancode and wmi event. > > > > > > New acer-wmi driver will transfer wmi event to keycode (e.g. > > > KEY_BLUETOOTH), if EC also emit KEY_BLUETOOTH, the rfkill-input will > > > > > > receive the key events twice, that means: > > > global BT block (when system boot) -> BT unblock (from EC scancode) -> > > > BT > > > > > > block (from acer-wmi) > > > > > > Could you please help me to check? > > > > > > - If your distro still have HAL, please run: > > > + lshal -l -m > > > + press BT HW key 1 time > > > then check does HAL receive KEY_BLUETOOTH twice? > > > > I didn't uninstall hal yet, so the output of `lshal -l -m` (only the > > monitoring part) when I press once BT HW key is attached. I've also > > patched the kernel to have more debug logging (see the attached diff and > > log) and the result is that the handler method from rfkill/input.c is > > not called, the global state is once set to "blocked" and it keeps like > > that. I don't know why the rfkill_event isn't called when I press the HW > > BT switch, it could be part of my investigations in the following days. > > > > I've attached .config too, if you want to check that I missed something > > that is needed by Acer WMI. > > > > Cheers, > > OldÅich. > > Per your lshal log, looks like HAL only receive the key event from EC > but didn't have key event from acer-wmi: > > *** 22:21:01.310: lshal: device_condition, > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_i > nput condition_name=ButtonPressed > condition_details=bluetooth //it's from standard input > > *** 22:21:02.076: lshal: property_modified, > udi=/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_bluetooth_bl > uetooth, key=killswitch.state is_removed=false, is_added=false > *** new value: 1 (0x1) (int) //UNBLOCK when you press BT HW key > > > So, there have only one KEY_BLUETOOTH from ec, acer-wmi didn't emit it. I > thought your machine didn't support Acer ACPI event GUIDs. Please dump the > dsdt to me, thank's: acpidump > acpidump.dat > > Then, if there only have one KEY_BLUETOOTH, why the global BT state didn't > change by rfill-input? Technically, rfkill-input must receive this key > then change global state: > > your situation: > initial press HW key > acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling) > global BLOCK BLOCK (why didn't changed by rfkill-input?) > hci0 none BLOCK (replicate from global) > > Like you said, the odd thing is: > "Why rfkill-input didn't receive KEY_BLUEOOTH from ec on your machine?" > > We need find out root cause, but I thought my last patch still works to fix > your situation and it make sense for Acer BIOS didn't really persistence > devices state. > > applied my patch: > initial press HW key > acer-wmi BLOCK UNBLOCK (changed by acer-wmi polling) > global UNBLOCK UNBLOCK (didn't changed by rfkill-input?) > hci0 none UNBLOCK (replicate from global) > > > Conclusion... > please kindly help to provide the following information: > > - Please provide DSDT to me > + I want to double check your BIOS didn't support acer wmi event. > > - Why rfkill-input didn't call by BT HW key? > + please remember disable urfkill daemon, it might disabled rfkill-input! > + please provide dmesg and messages log to me Here you are (dmesg, /var/log/messages, acpidump): http://others-misc.oldium.net/dump.tar.gz I hope this finally helps to find something :-) Cheers, OldÅich. > > > Thank's a lot! > Joey Lee > > -- > 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-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
