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]

 



Ho Joey Lee,

On Monday 28 March 2011 11:04:32 Joey Lee wrote:
> 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_logicald
> > > ev_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_bluetoot
> > > h_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

Works for me, I've put a comment on the bugreport.

Cheers,
OldÅich.

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