Hi OldÅic, æ äï2011-03-25 æ 20:22 +0100ïOldÅich JedliÄka æåï > 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. > I sand out patch to platform driver group for review: 0001-acer-wmi-does-not-set-persistence-state-by-rfkill_i.patch And added comment on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31002#c12 Thank's 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
