Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux