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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
