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_input
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_bluetooth,
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
Thank's a lot!
Joey Lee
--
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
