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?
- Or, please try the following patch, it removed
KEY_BLUETOOTH support in acer-wmi. If removed it but the BT killswitch
still can reserve when you press BT HW key, that means not just
acer-wmi emit KEY_BLUETOOTH:
Thank's a lot!
Joey Lee
>From 20b3b8ba26cb37c8a44d11645c2d8d1f5344cfd7 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi <[email protected]>
Date: Thu, 24 Mar 2011 21:07:43 +0800
Subject: [PATCH] remove KEY_BLUETOOTH for testing
Signed-off-by: Lee, Chun-Yi <[email protected]>
---
drivers/platform/x86/acer-wmi.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index c978470..554ee12 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -102,7 +102,6 @@ enum acer_wmi_event_ids {
static const struct key_entry acer_wmi_keymap[] = {
{KE_KEY, 0x01, {KEY_WLAN} }, /* WiFi */
- {KE_KEY, 0x12, {KEY_BLUETOOTH} }, /* BT */
{KE_KEY, 0x21, {KEY_PROG1} }, /* Backup */
{KE_KEY, 0x22, {KEY_PROG2} }, /* Arcade */
{KE_KEY, 0x23, {KEY_PROG3} }, /* P_Key */
--
1.6.0.2
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
