Re: acer-wmi: rfkill and bluetooth enabling doesn't work as in 2.6.37
From: Joey Lee <hidden>
Date: 2011-03-31 07:51:44
Hi Oldřich, 於 四，2011-03-31 於 08:43 +0200，Oldřich Jedlička 提到：
Hi Joey Lee,
2011/3/31 Oldřich Jedlička [off-list ref]
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.