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