æ åï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@xxxxxxxxx> > > 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@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
