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

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

[Joey Lee]

Removed bluetooth kernel mail for this issue not actually related to
bluetooth.
Added Dmitry Torokhov and linux-input@vger.kernel.org

Hi Oldřich,

於 五，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.
> 

Thank's for your information, I will look at it.

Finally,
I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your
situation.

The BAD thing is you are right, 
I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense
because rfkill-input registered input handler.

The BT HW key still works because acer-wmi have polling to sync the
state with EC and killswitch, and EC also take care the BT device power
off job.

But, I also found SOMETIMES after system reboot, rfkill-input can
capture the key event.
We need find out why input handle didn't receive KEY_* event.


Hi, Dmitry 

Appreciate if you can give us any good suggestions!
Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input
handler, can't capture it?

*** 06:32:42.972: lshal: device_condition,
udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input
           condition_name=ButtonPressed
           condition_details=bluetooth

But, SOMETIMES after reboot system, rfkill-input can capture the key.
We are working on 2.6.38 kernel, and Acer notebook.


Thank's a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dmitry Torokhov]

On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> 
> Thank's for your information, I will look at it.
> 
> Finally,
> I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your
> situation.
> 
> The BAD thing is you are right, 
> I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense
> because rfkill-input registered input handler.
> 
> The BT HW key still works because acer-wmi have polling to sync the
> state with EC and killswitch, and EC also take care the BT device power
> off job.
> 
> But, I also found SOMETIMES after system reboot, rfkill-input can
> capture the key event.
> We need find out why input handle didn't receive KEY_* event.
> 
> 
> Hi, Dmitry 
> 
> Appreciate if you can give us any good suggestions!
> Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input
> handler, can't capture it?
> 
> *** 06:32:42.972: lshal: device_condition,
> udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input
>            condition_name=ButtonPressed
>            condition_details=bluetooth
> 
> But, SOMETIMES after reboot system, rfkill-input can capture the key.
> We are working on 2.6.38 kernel, and Acer notebook.

Hi Joey,

If you look in /proc/bus/input/devices do you see rfkill-input as
actually bound to the device that has KEY_BLUETOOTH?

Since it is atkbd that is emitting KEY_BLUETOOTH and this key is not in
the default keymap I think you must be loading Acer-specific keymap via
udev or some other mechanism, and I guess stumbling upon a deficiency in
input layer: we do not re-match devices after changing keymap. So if
rfkill-input was loaded before keymap was altered, then it will not bind
to the keyboard even if you add KE_BLUETOOTH at a later time. Fixing
this is something that was on my TODO list for a while now...

Thaks.

-- 
Dmitry

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

[Joey Lee]

Hi Dmitry,

於 日，2011-03-27 於 10:09 -0700，Dmitry Torokhov 提到：
> On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > 
> > Thank's for your information, I will look at it.
> > 
> > Finally,
> > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your
> > situation.
> > 
> > The BAD thing is you are right, 
> > I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense
> > because rfkill-input registered input handler.
> > 
> > The BT HW key still works because acer-wmi have polling to sync the
> > state with EC and killswitch, and EC also take care the BT device power
> > off job.
> > 
> > But, I also found SOMETIMES after system reboot, rfkill-input can
> > capture the key event.
> > We need find out why input handle didn't receive KEY_* event.
> > 
> > 
> > Hi, Dmitry 
> > 
> > Appreciate if you can give us any good suggestions!
> > Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input
> > handler, can't capture it?
> > 
> > *** 06:32:42.972: lshal: device_condition,
> > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input
> >            condition_name=ButtonPressed
> >            condition_details=bluetooth
> > 
> > But, SOMETIMES after reboot system, rfkill-input can capture the key.
> > We are working on 2.6.38 kernel, and Acer notebook.
> 
> Hi Joey,
> 
> If you look in /proc/bus/input/devices do you see rfkill-input as
> actually bound to the device that has KEY_BLUETOOTH?
> 

Like you said, we fell into the trap:

Fail case:

linux-uy92:/proc/bus/input # vi devices

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input0
U: Uniq=
H: Handlers=sysrq kbd event0
B: PROP=0
B: EV=120013
B: KEY=10000 c0200 0 0 0 0 0 700f 2000003 3803078 f830f401 febfffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7


Success case:

linux-uy92:/proc/bus/input # vi devices 

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input0
U: Uniq=
H: Handlers=sysrq kbd event0 rfkill
B: PROP=0
B: EV=120013
B: KEY=10000 c0200 0 0 0 0 0 700f 2000003 3803078 f830f401 febfffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7


In fail case, rfkill didn't register to keyboard's Handlers. And, I also
checked the rfkill-input's .connect didn't call by input when system
boot:

Fail case:

[    7.144252] rfkill: rfkill_handler_init
[    7.144277] rfkill: rfkill_handler_init, start input_register_handler


Success case:

[    7.580683] rfkill: rfkill_handler_init
[    7.580714] rfkill: rfkill_handler_init, start input_register_handler
[    7.580737] rfkill: doing input_register_handle

> Since it is atkbd that is emitting KEY_BLUETOOTH and this key is not in
> the default keymap I think you must be loading Acer-specific keymap via
> udev or some other mechanism, and I guess stumbling upon a deficiency in
> input layer: we do not re-match devices after changing keymap. So if
> rfkill-input was loaded before keymap was altered, then it will not bind
> to the keyboard even if you add KE_BLUETOOTH at a later time. Fixing
> this is something that was on my TODO list for a while now...
> 
> Thaks.
> 

Yes,
this a race condition for rfkill-input register before udev set
Acer-specific keymap. 

We didn't find it just because old acer-wmi driver hide the BIOS default
devices states and always set bluetooth state to enabled when system
boot.


Thank's
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Oldřich Jedlička]

Hi Dmitry,

On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > Thank's for your information, I will look at it.
> > 
> > Finally,
> > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce your
> > situation.
> > 
> > The BAD thing is you are right,
> > I CAN REPRODUCE rfkill-input didn't receive any input, it not make sense
> > because rfkill-input registered input handler.
> > 
> > The BT HW key still works because acer-wmi have polling to sync the
> > state with EC and killswitch, and EC also take care the BT device power
> > off job.
> > 
> > But, I also found SOMETIMES after system reboot, rfkill-input can
> > capture the key event.
> > We need find out why input handle didn't receive KEY_* event.
> > 
> > 
> > Hi, Dmitry
> > 
> > Appreciate if you can give us any good suggestions!
> > Why keyboard emit KEY_BLUETOOTH, but rfkill-input, registered input
> > handler, can't capture it?
> > 
> > *** 06:32:42.972: lshal: device_condition,
> > udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev
> > _input
> > 
> >            condition_name=ButtonPressed
> >            condition_details=bluetooth
> > 
> > But, SOMETIMES after reboot system, rfkill-input can capture the key.
> > We are working on 2.6.38 kernel, and Acer notebook.
> 
> Hi Joey,
> 
> If you look in /proc/bus/input/devices do you see rfkill-input as
> actually bound to the device that has KEY_BLUETOOTH?
> 
> Since it is atkbd that is emitting KEY_BLUETOOTH and this key is not in
> the default keymap I think you must be loading Acer-specific keymap via
> udev or some other mechanism, and I guess stumbling upon a deficiency in
> input layer: we do not re-match devices after changing keymap. So if
> rfkill-input was loaded before keymap was altered, then it will not bind
> to the keyboard even if you add KE_BLUETOOTH at a later time. Fixing
> this is something that was on my TODO list for a while now...

Verified - I tried to compile rfkill as module as you recommended (on personal 
e-mail). I had to reload rfkill after startup to have rfkill listening. So 
this part looks clear on what happens.

@Joey Lee: There are other strange situations when I have rfkill as a module 
and don't have acer-wmi loaded (every second try hci0 rfkill is blocked, the 
other try it is unblocked) and more strange situation is when acer-wmi gets 
loaded (accidentally I've tried it when the BT hci0 was up and running) - the 
BT switch brings hci0 to light after the second press (no action on the first 
one), next press switched it off. I was able to reproduce both "problems" 
several times with no randomness in it.

Cheers,
Oldřich.

> 
> Thaks.

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

[Joey Lee]

Hi Oldřich, 

於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
> Hi Joey Lee,
> 
> 2011/3/31 Oldřich Jedlička <oldium.pro@seznam.cz>
>         Hi Dmitry,
>         
>         On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
>         > On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
>         > > Thank's for your information, I will look at it.
>         > >
>         > > Finally,
>         > > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce
>         your
>         > > situation.
>         > >
>         > > The BAD thing is you are right,
>         > > I CAN REPRODUCE rfkill-input didn't receive any input, it
>         not make sense
>         > > because rfkill-input registered input handler.
>         > >
>         > > The BT HW key still works because acer-wmi have polling to
>         sync the
>         > > state with EC and killswitch, and EC also take care the BT
>         device power
>         > > off job.
>         > >
>         > > But, I also found SOMETIMES after system reboot,
>         rfkill-input can
>         > > capture the key event.
>         > > We need find out why input handle didn't receive KEY_*
>         event.
>         > >
>         > >
>         > > Hi, Dmitry
>         > >
>         > > Appreciate if you can give us any good suggestions!
>         > > Why keyboard emit KEY_BLUETOOTH, but rfkill-input,
>         registered input
>         > > handler, can't capture it?
>         > >
>         
>         > > *** 06:32:42.972: lshal: device_condition,
>         > >
>         udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev
>         > > _input
>         > >
>         > >            condition_name=ButtonPressed
>         > >            condition_details=bluetooth
>         > >
>         
>         > > But, SOMETIMES after reboot system, rfkill-input can
>         capture the key.
>         > > We are working on 2.6.38 kernel, and Acer notebook.
>         >
>         > Hi Joey,
>         >
>         > If you look in /proc/bus/input/devices do you see
>         rfkill-input as
>         > actually bound to the device that has KEY_BLUETOOTH?
>         >
>         
>         > Since it is atkbd that is emitting KEY_BLUETOOTH and this
>         key is not in
>         > the default keymap I think you must be loading Acer-specific
>         keymap via
>         > udev or some other mechanism, and I guess stumbling upon a
>         deficiency in
>         > input layer: we do not re-match devices after changing
>         keymap. So if
>         > rfkill-input was loaded before keymap was altered, then it
>         will not bind
>         > to the keyboard even if you add KE_BLUETOOTH at a later
>         time. Fixing
>         > this is something that was on my TODO list for a while
>         now...
>         
>         
>         Verified - I tried to compile rfkill as module as you
>         recommended (on personal
>         e-mail). I had to reload rfkill after startup to have rfkill
>         listening. So
>         this part looks clear on what happens.
>         
>         @Joey Lee: There are other strange situations when I have
>         rfkill as a module
>         and don't have acer-wmi loaded (every second try hci0 rfkill
>         is blocked, the
>         other try it is unblocked) and more strange situation is when
>         acer-wmi gets
>         loaded (accidentally I've tried it when the BT hci0 was up and
>         running) - the
>         BT switch brings hci0 to light after the second press (no
>         action on the first
>         one), next press switched it off. I was able to reproduce both
>         "problems"
>         several times with no randomness in it.
> 
> Sorry, that was probably caused by the fact that the bluetooth
> on-to-off scancode isn't mapped correctly (0xD9 emits brightness-up
> instead of bluetooth). I have the updated keymap already, but it
> doesn't get loaded automatically cu> this was also the case during my tests. I will try it with the correct
> keymap later too.
> 
> Cheers,
> Oldřich.
>  

Yes, I just also simply try, the EC emit key priority is:
	KEY_BLUETOOTH
	KEY_BRIGHTNESSUP
	KEY_BLUETOOTH
	KEY_BLUETOOTH

You are right, maybe the keymaping have problem on speciall acer
notebook, I will also try.


Thank's
Joey Lee

>         Cheers,
>         Oldřich.
>         
>         >
>         > Thaks.
> 

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

[Joey Lee]

於 四，2011-03-31 於 01:51 -0600，Joey Lee 提到：
> Hi Oldřich, 
> 
> 於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
> > Hi Joey Lee,
> > 
> > 2011/3/31 Oldřich Jedlička <oldium.pro@seznam.cz>
> >         Hi Dmitry,
> >         
> >         On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> >         > On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> >         > > Thank's for your information, I will look at it.
> >         > >
> >         > > Finally,
> >         > > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce
> >         your
> >         > > situation.
> >         > >
> >         > > The BAD thing is you are right,
> >         > > I CAN REPRODUCE rfkill-input didn't receive any input, it
> >         not make sense
> >         > > because rfkill-input registered input handler.
> >         > >
> >         > > The BT HW key still works because acer-wmi have polling to
> >         sync the
> >         > > state with EC and killswitch, and EC also take care the BT
> >         device power
> >         > > off job.
> >         > >
> >         > > But, I also found SOMETIMES after system reboot,
> >         rfkill-input can
> >         > > capture the key event.
> >         > > We need find out why input handle didn't receive KEY_*
> >         event.
> >         > >
> >         > >
> >         > > Hi, Dmitry
> >         > >
> >         > > Appreciate if you can give us any good suggestions!
> >         > > Why keyboard emit KEY_BLUETOOTH, but rfkill-input,
> >         registered input
> >         > > handler, can't capture it?
> >         > >
> >         
> >         > > *** 06:32:42.972: lshal: device_condition,
> >         > >
> >         udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev
> >         > > _input
> >         > >
> >         > >            condition_name=ButtonPressed
> >         > >            condition_details=bluetooth
> >         > >
> >         
> >         > > But, SOMETIMES after reboot system, rfkill-input can
> >         capture the key.
> >         > > We are working on 2.6.38 kernel, and Acer notebook.
> >         >
> >         > Hi Joey,
> >         >
> >         > If you look in /proc/bus/input/devices do you see
> >         rfkill-input as
> >         > actually bound to the device that has KEY_BLUETOOTH?
> >         >
> >         
> >         > Since it is atkbd that is emitting KEY_BLUETOOTH and this
> >         key is not in
> >         > the default keymap I think you must be loading Acer-specific
> >         keymap via
> >         > udev or some other mechanism, and I guess stumbling upon a
> >         deficiency in
> >         > input layer: we do not re-match devices after changing
> >         keymap. So if
> >         > rfkill-input was loaded before keymap was altered, then it
> >         will not bind
> >         > to the keyboard even if you add KE_BLUETOOTH at a later
> >         time. Fixing
> >         > this is something that was on my TODO list for a while
> >         now...
> >         
> >         
> >         Verified - I tried to compile rfkill as module as you
> >         recommended (on personal
> >         e-mail). I had to reload rfkill after startup to have rfkill
> >         listening. So
> >         this part looks clear on what happens.
> >         
> >         @Joey Lee: There are other strange situations when I have
> >         rfkill as a module
> >         and don't have acer-wmi loaded (every second try hci0 rfkill
> >         is blocked, the
> >         other try it is unblocked) and more strange situation is when
> >         acer-wmi gets
> >         loaded (accidentally I've tried it when the BT hci0 was up and
> >         running) - the
> >         BT switch brings hci0 to light after the second press (no
> >         action on the first
> >         one), next press switched it off. I was able to reproduce both
> >         "problems"
> >         several times with no randomness> > Sorry, that was probably caused by the fact that the bluetooth
> > on-to-off scancode isn't mapped correctly (0xD9 emits brightness-up
> > instead of bluetooth). I have the updated keymap already, but it
> > doesn't get loaded automatically cu> this was also the case during my tests. I will try it with the correct
> > keymap later too.
> > 
> > Cheers,
> > Oldřich.
> >  
> 
> Yes, I just also simply try, the EC emit key priority is:
> 	KEY_BLUETOOTH
> 	KEY_BRIGHTNESSUP
> 	KEY_BLUETOOTH
> 	KEY_BLUETOOTH
> 
> You are right, maybe the keymaping have problem on speciall acer
> notebook, I will also try.
> 
> 
> Thank's
> Joey Lee
> 

Set 0xD9=bluetooth in udev keymap works fine to me both on acer-wmi
probe or not.
But, on my Acer AspireOne ZG8, there have no product name in
dmidecode...


Thank's
Joey Lee

> >         Cheers,
> >         Oldřich.
> >         
> >         >
> >         > Thaks.
> > 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
> the body of a message to majordomo@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Joey Lee]

Hi Oldřich,

於 四，2011-03-31 於 02:09 -0600，Joey Lee 提到：
> 於 四，2011-03-31 於 01:51 -0600，Joey Lee 提到：
> > Hi Oldřich, 
> > 
> > 於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
> > > Hi Joey Lee,
> > > 
> > > 2011/3/31 Oldřich Jedlička <oldium.pro@seznam.cz>
> > >         Hi Dmitry,
> > >         
> > >         On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> > >         > On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > >         > > Thank's for your information, I will look at it.
> > >         > >
> > >         > > Finally,
> > >         > > I borrow a Acer Aspire one ZG8 from Gary, it can reproduce
> > >         your
> > >         > > situation.
> > >         > >
> > >         > > The BAD thing is you are right,
> > >         > > I CAN REPRODUCE rfkill-input didn't receive any input, it
> > >         not make sense
> > >         > > because rfkill-input registered input handler.
> > >         > >
> > >         > > The BT HW key still works because acer-wmi have polling to
> > >         sync the
> > >         > > state with EC and killswitch, and EC also take care the BT
> > >         device power
> > >         > > off job.
> > >         > >
> > >         > > But, I also found SOMETIMES after system reboot,
> > >         rfkill-input can
> > >         > > capture the key event.
> > >         > > We need find out why input handle didn't receive KEY_*
> > >         event.
> > >         > >
> > >         > >
> > >         > > Hi, Dmitry
> > >         > >
> > >         > > Appreciate if you can give us any good suggestions!
> > >         > > Why keyboard emit KEY_BLUETOOTH, but rfkill-input,
> > >         registered input
> > >         > > handler, can't capture it?
> > >         > >
> > >         
> > >         > > *** 06:32:42.972: lshal: device_condition,
> > >         > >
> > >         udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev
> > >         > > _input
> > >         > >
> > >         > >            condition_name=ButtonPressed
> > >         > >            condition_details=bluetooth
> > >         > >
> > >         
> > >         > > But, SOMETIMES after reboot system, rfkill-input can
> > >         capture the key.
> > >         > > We are working on 2.6.38 kernel, and Acer notebook.
> > >         >
> > >         > Hi Joey,
> > >         >
> > >         > If you look in /proc/bus/input/devices do you see
> > >         rfkill-input as
> > >         > actually bound to the device that has KEY_BLUETOOTH?
> > >         >
> > >         
> > >         > Since it is atkbd that is emitting KEY_BLUETOOTH and this
> > >         key is not in
> > >         > the default keymap I think you must be loading Acer-specific
> > >         keymap via
> > >         > udev or some other mechanism, and I guess stumbling upon a
> > >         deficiency in
> > >         > input layer: we do not re-match devices after changing
> > >         keymap. So if
> > >         > rfkill-input was loaded before keymap was altered, then it
> > >         will not bind
> > >         > to the keyboard even if you add KE_BLUETOOTH at a later
> > >         time. Fixing
> > >         > this is something that was on my TODO list for a while
> > >         now...
> > >         
> > >         
> > >         Verified - I tried to compile rfkill as module as you
> > >         recommended (on personal
> > >         e-mail). I had to reload rfkill after startup to have rfkill
> > >         listening. So
> > >         this part looks clear on what happens.
> > >         
> > >         @Joey Lee: There are other strange situations when I have
> > >         rfkill as a module
> > >         and don't have acer-wmi loaded (every second try hci0 rfkill
> > >         is blocked, the
> > >         other try it is unblocked) and more strange situation is when
> > >         acer-wmi gets
> > >         loaded (accidentally I've tried it when the BT hci0 was up and
> > >         r> > >         BT switch brings hci0 to light after the second press (no
> > >         action on the first
> > >         one), next press switched it off. I was able to reproduce both
> > >         "problems"
> > >         several times with no randomness> > Sorry, that was probably caused by the fact that the bluetooth
> > > on-to-off scancode isn't mapped correctly (0xD9 emits brightness-up
> > > instead of bluetooth). I have the updated keymap already, but it
> > > doesn't get loaded automatically cu> this was also the case during my tests. I will try it with the correct
> > > keymap later too.
> > > 
> > > Cheers,
> > > Oldřich.
> > >  
> > 
> > Yes, I just also simply try, the EC emit key priority is:
> > 	KEY_BLUETOOTH
> > 	KEY_BRIGHTNESSUP
> > 	KEY_BLUETOOTH
> > 	KEY_BLUETOOTH
> > 
> > You are right, maybe the keymaping have problem on speciall acer
> > notebook, I will also try.
> > 
> > 
> > Thank's
> > Joey Lee
> > 
> 
> Set 0xD9=bluetooth in udev keymap works fine to me both on acer-wmi
> probe or not.
> But, on my Acer AspireOne ZG8, there have no product name in
> dmidecode...
> 

OK, confirm acer-aspire_5720 keymap works fine on my ZG8. I added the
following rule to /lib/udev/rules.d/95-keymap.rules:

ENV{DMI_VENDOR}=="Acer*", ATTR{[dmi/id]product_serial}=="ZG8*", RUN+="keymap $name acer-aspire_5720"

I will send patch to udev group. But I am not sure acer-aspire_5720 keymap also works to you:

0x84 bluetooth  # sent when bluetooth module missing, and key pressed
0x92 media      # acer arcade
0xD4 bluetooth  # bluetooth on
0xD9 bluetooth  # bluetooth off

Do you need me help to send out patch to udev group for your machine? 


Thank's 
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Oldřich Jedlička]

Hi Joey Lee,

On Thursday 31 March 2011 11:10:49 Joey Lee wrote:
> Hi Oldřich,
> 
> 於 四，2011-03-31 於 02:09 -0600，Joey Lee 提到：
> 
> > 於 四，2011-03-31 於 01:51 -0600，Joey Lee 提到：
> > 
> > > Hi Oldřich,
> > > 
> > > 於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
> > > 
> > > > Hi Joey Lee,
> > > > 
> > > > 2011/3/31 Oldřich Jedlička <oldium.pro@seznam.cz>
> > > > 
> > > >         Hi Dmitry,
> > > >         
> > > >         On Sunday 27 March 2011 19:09:29 Dmitry Torokhov wrote:
> > > >         > On Fri, Mar 25, 2011 at 04:35:46PM -0600, Joey Lee wrote:
> > > >         > > Thank's for your information, I will look at it.
> > > >         > > 
> > > >         > > Finally,
> > > >         > > I borrow a Acer Aspire one ZG8 from Gary, it can
> > > >         > > reproduce
> > > >         
> > > >         your
> > > >         
> > > >         > > situation.
> > > >         > > 
> > > >         > > The BAD thing is you are right,
> > > >         > > I CAN REPRODUCE rfkill-input didn't receive any input, it
> > > >         
> > > >         not make sense
> > > >         
> > > >         > > because rfkill-input registered input handler.
> > > >         > > 
> > > >         > > The BT HW key still works because acer-wmi have polling
> > > >         > > to
> > > >         
> > > >         sync the
> > > >         
> > > >         > > state with EC and killswitch, and EC also take care the
> > > >         > > BT
> > > >         
> > > >         device power
> > > >         
> > > >         > > off job.
> > > >         > > 
> > > >         > > But, I also found SOMETIMES after system reboot,
> > > >         
> > > >         rfkill-input can
> > > >         
> > > >         > > capture the key event.
> > > >         > > We need find out why input handle didn't receive KEY_*
> > > >         
> > > >         event.
> > > >         
> > > >         > > Hi, Dmitry
> > > >         > > 
> > > >         > > Appreciate if you can give us any good suggestions!
> > > >         > > Why keyboard emit KEY_BLUETOOTH, but rfkill-input,
> > > >         
> > > >         registered input
> > > >         
> > > >         > > handler, can't capture it?
> > > >         > > 
> > > >         > > 
> > > >         > > *** 06:32:42.972: lshal: device_condition,
> > > >         
> > > >         udi=/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_por
> > > >         t_logicaldev
> > > >         
> > > >         > > _input
> > > >         > > 
> > > >         > >            condition_name=ButtonPressed
> > > >         > >            condition_details=bluetooth
> > > >         > > 
> > > >         > > But, SOMETIMES after reboot system, rfkill-input can
> > > >         
> > > >         capture the key.
> > > >         
> > > >         > > We are working on 2.6.38 kernel, and Acer notebook.
> > > >         > 
> > > >         > Hi Joey,
> > > >         > 
> > > >         > If you look in /proc/bus/input/devices do you see
> > > >         
> > > >         rfkill-input as
> > > >         
> > > >         > actually bound to the device that has KEY_BLUETOOTH?
> > > >         > 
> > > >         > 
> > > >         > Since it is atkbd that is emitting KEY_BLUETOOTH and this
> > > >         
> > > >         key is not in
> > > >         
> > > >         > the default keymap I think you must be loading
> > > >         > Acer-specific
> > > >         
> > > >         keymap via
> > > >         
> > > >         > udev or some other mechanism, and I guess stumbling upon a
> > > >         
> > > >         deficiency in
> > > >         
> > > >         > input layer: we do not re-match devices after changing
> > > >         
> > > >         keymap. So if
> > > >         
> > > >         > rfkill-input was loaded before keymap was altered, then it
> > > >         
> > > >         will not bind
> > > >         
> > > >         > to the keyboard even if you add KE_BLUETOOTH at a later
> > > >         
> > > >         time. Fixing
> > > >         
> > > >         > this is something that was on my TODO list for a while
> > > >         
> > > >         now...
> > > >         
> > > >         
> > > >         Verified - I tried to compile rfkill as module as you
> > > >         recommended (on personal
> > > >         e-mail). I had to reload rfkill after startup to have rfkill
> > > >         listening. So
> > > >         this part looks clear on what happens.
> > > >         
> > > >         @Joey Lee: There are other strange situations when I have
> > > >         rfkill as a module
> > > >         and don't have acer-wmi loaded (every second try hci0 rfkill
> > > >         is blocked, the
> > > >         other try it is unblocked) and more strange situation is when
> > > >         acer-wmi gets
> > > >         loaded (accidentally I've tried it when the BT hci0 was up
> > > >         and r> > >         BT switch brings hci0 to light after the
> > > >         second press (no action on the first
> > > >         one), next press switched it off. I was able to reproduce
> > > >         both "problems"
> > > >         several times with no randomness> > Sorry, that was probably
> > > >         caused by the fact that the bluetooth
> > > > 
> > > > on-to-off scancode isn't mapped correctly (0xD9 emits brightness-up
> > > > instead of bluetooth). I have the updated keymap already, but it
> > > > doesn't get loaded automatically cu> this was also the case during my
> > > > tests. I will try it with the correct keymap later too.
> > > > 
> > > > Cheers,
> > > > Oldřich.
> > > 
> > > Yes, I just also simply try, the EC emit key priority is:
> > > 	KEY_BLUETOOTH
> > > 	KEY_BRIGHTNESSUP
> > > 	KEY_BLUETOOTH
> > > 	KEY_BLUETOOTH
> > > 
> > > You are right, maybe the keymaping have problem on speciall acer
> > > notebook, I will also try.
> > > 
> > > 
> > > Thank's
> > > Joey Lee
> > 
> > Set 0xD9=bluetooth in udev keymap works fine to me both on acer-wmi
> > probe or not.
> > But, on my Acer AspireOne ZG8, there have no product name in
> > dmidecode...
> 
> OK, confirm acer-aspire_5720 keymap works fine on my ZG8. I added the
> following rule to /lib/udev/rules.d/95-keymap.rules:
> 
> ENV{DMI_VENDOR}=="Acer*", ATTR{[dmi/id]product_serial}=="ZG8*",
> RUN+="keymap $name acer-aspire_5720"
> 
> I will send patch to udev group. But I am not sure acer-aspire_5720 keymap
> also works to you:
>
> 0x84 bluetooth  # sent when bluetooth module missing, and key pressed
> 0x92 media      # acer arcade
> 0xD4 bluetooth  # bluetooth on
> 0xD9 bluetooth  # bluetooth off

Yes, that would work. I've sent already keymap to linux-hotplug mailing list 
(with a note to update the meanings to be in-line with other keymaps):

0xD9 bluetooth # (toggle) off-to-on                                                                                  
0xF1 touchpad_on # (toggle) off-to-on                                                                                
0xF2 touchpad_off # (toggle) on-to-off                                                                               
0xF9 connect # Sync                                                                                                  
0xEE screenlock # Lock                                                                                               

My keymap problem was caused by started `hald`, which reset the keymap to some 
bad one. I've removed hald from startup and the keys are mapped well now. Also 
the starting of bluetooth with BT HW button works as expected now.

> Do you need me help to send out patch to udev group for your machine?

Thanks, not necessary.

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html