Ho Joey Lee, On Monday 28 March 2011 11:04:32 Joey Lee wrote: > 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_logicald > > > ev_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_bluetoot > > > h_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 Works for me, I've put a comment on the bugreport. Cheers, OldÅich. > 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 -- 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
