Removed bluetooth kernel mail for this issue not actually related to bluetooth. Added Dmitry Torokhov and linux-input@xxxxxxxxxxxxxxx Hi OldÅich, æ äï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. > Thank's for your information, I will look at it. Finally, I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your situation. The BAD thing is you are right, I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense because rfkill-input registered input handler. The BT HW key still works because acer-wmi have polling to sync the state with EC and killswitch, and EC also take care the BT device power off job. But, I also found SOMETIMES after system reboot, rfkill-input can capture the key event. We need find out why input handle didn't receive KEY_* event. Hi, Dmitry Appreciate if you can give us any good suggestions! Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input handler, can't capture it? *** 06:32:42.972: lshal: device_condition, udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input condition_name=ButtonPressed condition_details=bluetooth But, SOMETIMES after reboot system, rfkill-input can capture the key. We are working on 2.6.38 kernel, and Acer notebook. 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
