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.