Lenovo Y550A - monitor settings and wireless settings buttons not work

> I test it using xv
I mean xev.

Also, OneKey Recovery (separate hardware button) not work too (not recognized even xev)

I tried use tp-smapi-dkms for detect this buttons, but it's not work for me with error: No such device.

https://bugzilla.kernel.org/show_bug.cgi?id=16002

Two tests you can proceed:
  1. kill acpid and run `acpi_listen`. see if any ACPI event when you press the keys.
  2. `sudo /lib/udev/keymap -i input/eventX`. X is number, check `ls /dev/input/` for all the events. see if any scancode shows up when pressing the keys.

> see if any ACPI event when you press the keys.
Nothing.
> see if any scancode shows up when pressing the keys.
I check all event from 0 to 11, but still nothing.

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Please exercise the steps at https://wiki.ubuntu.com/Hotkeys/Troubleshooting to determine at which level your hotkey problems occur, and attach the collected information. Most probably the keys will produce an unknown or wrong key code with the "keymap" tool, in which case you need to follow /usr/share/doc/udev/README.keymap.txt.gz to determine the scan code - key code mapping for the broken/missing keys.

Thank you!

> https://wiki.ubuntu.com/Hotkeys/Troubleshooting
I follow this document, but looks like "kernel not translating the ACPI event to an input event".

"sudo /lib/udev/keymap -i input/event4" not shown any reaction to Fn+F4 and Fn+F5 in my case.
Also I see the two other possible problems:
1. Fn+F3 (button for switch between laptop LCD and external monitor) generate same scancode like "p" button.
2. PrtScr and Fn+PrtScr generate same scancode, but Fn+PrtScr must generate SysRq scancode.

When I test I found the BIOS of this laptop have "key release" event problem. Desktop sticks many times while testing. If it possible to fix using BIOS update, what I can exactly request from this laptop manufacturer for fixing in next BIOS update? I mean there is any description of the problem in technical language?

Adding a Linux task for the two keys which don't produce any scan code.

As for the sticky keys, we can add a quirk to udev for them. Which scan codes behave that way? (find out with keymap -i as you did before).

> Adding a Linux task for the two keys which don't produce any scan code.
Same problem with X.org?

> As for the sticky keys, we can add a quirk to udev for them. Which scan codes behave that way?
Looks like problem with Fn button. If I press and release it - there is no problem, but typically this button used with F1-F12 buttons, and then I press it few second until I press F1-F12 button too. Hold this button stick desktop while testing (when keymap -i is launched), but not gererate any scancode. This is expected behaviour for Fn button?

No, this isn't expected. Freezing the desktop *and* not producing any scan code is an entirely new phenomenon which I never encountered before. To be sure, can you please check whether pressing Ctrl+Alt+F1 (to switch to a text console) and then Ctrl+Alt+F7 or Ctrl+Alt+F8 (to switch back to the graphical desktop) will cure the hang?

Also, can you please doublecheck that you ran keymap against the correct input device? Do you see scan codes for the other keys there?

> To be sure, can you please check whether pressing Ctrl+Alt+F1 (to switch to a text console) and then Ctrl+Alt+F7 or Ctrl+Alt+F8 (to switch back to the graphical desktop) will cure the hang?
I can not switch. What exactly I do:
1. Press Fn one or few second, or Fn and of F1-F12 buttons (It's also take one or few seconds).
If I press and release in a short time problem not reproduced.
2. Launch "sudo /lib/udev/keymap -i input/event4". Because I press Fn button before keymap tool put many empty lines to stdout.
3. Try to switch to another VT as usual, but without success. Keymap show scancodes of Ctrl, Alt and F1, but system not switch to first VT. (I also try other VT's with same result)
Result of this try you can see in attached log - many empty lines generated by pressing Fn button, and Ctrl, Alt, F1 scancodes.

Also I try to launch keymap tool in VT - it's suddenly, but hangs bug not reproduced in VT at all - only in GUI (I try both of Gnome and KDE). Fn button still not generate scancode, in keymap launchad in VT tool too.

> Also, can you please doublecheck that you ran keymap against the correct input device? Do you see scan codes for the other keys there?
Yes, sure. All other keyboard button, except Fn button.

The Fn button alone isn't supposed to produce a scan code; that's already handled by the BIOS, which just sends a different scan code for a particular key depending whether or not Fn was pressed. I really meant "Fn + another key".

So let's see whether I understood you: If you press e. g. Fn+F1 quickly, you don't get a hang, right? Do you get a scan code with the keymap tool? I need these scan codes in order to fix the problem. If you press it longer, and thus activate the automatic repeat, you do get a hang?

> Fn+F1 quickly, you don't get a hang, right?
Right.

> Do you get a scan code with the keymap tool?
No.
Also:
When I press Fn+F1 I see "sleep" scancode
When I press Fn+F6 (enable/disable touchpad) touchpad is disabled, but keymap not show any scancode for this button. The same with Fn+Esc (enable/disable webcam).

> If you press it longer, and thus activate the automatic repeat, you do get a hang?
Yes, but only if I launch keymap tool in DE.

So, which particular scan codes do you see which cause hangs? I need the actual numbers, plus the output of

 grep . /sys/class/dmi/id/*

Thanks!

Futher investigation revealed:
1. Hang after launch keymap tool appear if I hold any button, not only Fn+Fx, before.
2. Bug easly reproduced not only on this Lenovo laptop, but on any other very different laptops and desktops.
I think you can reproduce this bug on your computer.

How to reproduce:
1. Press any button few seconds.
2. Launch keymap tool.
3. Then you see a hang. Hang look like you press Enter button and hold it. All aplication (Terminal Emulator, DE, browsers, office, etc.) functions as if you hold Enter.

> I need the actual numbers, plus the output of grep . /sys/class/dmi/id/* Thanks!
Already available here: http://bugs.launchpad.net/xorg-server/+bug/543065/comments/48

Hello,

RussianNeuroMancer [2010-10-01 22:38 -0000]:
> Futher investigation revealed:
> 1. Hang after launch keymap tool appear if I hold any button, not only Fn+Fx, before.

The eternal spill of new lines indeed does happen sometimes, but it's
unrelated to the hang on pressing Fn+Fx.

> > I need the actual numbers, plus the output of grep . /sys/class/dmi/id/* Thanks!
> Already available here: http://bugs.launchpad.net/xorg-server/+bug/543065/comments/48

This only provides the DMI output, but not the scan codes of the
Fn+F.. keys which cause the computer to hang.

> The eternal spill of new lines indeed does happen sometimes
When I say hang I mean that "eternal spill of new lines", because when it's happened it's looks like a hang in other (except terminal emulator) applications.

So, because some buttons not produce scan code but work (like enable/disable touchpad Fn+F6 in Lenovo Y550A case) how can I get scancodes of other buttons, what not show anything in keymap tool? (Fn+F4, Fn+F5) There is any way to do it?

> So, because some buttons not produce scan code but work (like enable/disable touchpad Fn+F6 in Lenovo Y550A case) how can I get scancodes of other buttons, what not show anything in keymap tool?

That needs to be fixed in the kernel, I'm afraid. I'll keep the kernel task open and close the udev task.

Results of testing with kernel 3.6.2:
OneKey Recovery button (keycode 156) now detected (as "XF86Launch1") but Ubuntu backup settings is doesn't opened when user press this button. Probably because there is no hotkeys assigned to Ubuntu backup application. Is there special hotkey that may be used for backup application? If yes, I guess "OneKey Recovery button" should be reassigned to trigger this hotkey. (I doesn't sure I use correct terminology when I use "hotkey" word, so if I wrong please correct me.)
Fn+F3 button (keycode 33) now detected as "p" button. As I understand it's should switch displays but not print symbol.
Fn+F4 button (keycode 194) now detected as XF86Launch7. Display settings is doesn't open when I press on this button. With stock Quantal kernel 3.5 this button doesn't detected.
Fn+F5 button (keycode 246) now detected as XF86WLAN, so this button works now.

I guess now udev task may be reopened.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

RussianNeuroMancer, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Hello!
kernel-fixed-upstream-3.6 is already in place.