Removed bluetooth kernel mail for this issue not actually related to
bluetooth.
Added Dmitry Torokhov and linux-input@vger.kernel.org

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:

quoted

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 提到：

quoted

Hi Joey Lee,

I've done some experiments, here are the results.

On Thursday 24 March 2011 14:13:29 Joey Lee wrote:

quoted

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 提到：

quoted

Hi Oldřich,

quoted

quoted

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) 

->

quoted

quoted

quoted

	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

quoted

*** 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

quoted

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-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html