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Åic,

æ äï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.
> 

I sand out patch to platform driver group for review:
0001-acer-wmi-does-not-set-persistence-state-by-rfkill_i.patch

And added comment on bugzilla:
	https://bugzilla.kernel.org/show_bug.cgi?id=31002#c12


Thank's
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