hotkey-setup support for MSI PR200

[matejcik]

Binary package hint: hotkey-setup

the hotkey-setup script does not have support for hotkeys on MSI PR200 notebook. Attached are the informations necessary to add the support (please tell me if i missed something).

I assume that the fix will work for PR210 as well, because keyboard layout is basically the same, but i tested only on PR200.

The hotkey codes are same as for MSI Infinity series (micro-star-infinity.hk), except for the following differences:
- "Fn+F3 touchpad disable" item does not apply - this key works out of the box, so it's either a different scancode that's already known, or it's handled outside hotkey-setup
(sorry if i'm babbling nonsense, i don't understand hotkeys too well, only to make my laptop work ;) )
- "envelope", "e" and "magnifying glass keys" ($KEY_MAIL, $KEY_WWW and $KEY_SEARCH) are not present on PR200. setting the keycodes seems to do no harm, though
- keycode e06e (key labeled "P2") turns webcam on/off. it worked out of the box, too, but generated noise about unknown scancode in dmesg. i mapped it to $KEY_CAMERA

There is one more hotkey, P1, which is "programmable key", but i was unable to find out its scancode. it doesn't seem to do anything - X won't see it and it doesn't put any messages into dmesg. Please tell me how to find out what key is it and how to enable it.

[matejcik (matejcik)]

okay ... i take back the patches, because the brightness key mappings make gnome-power-manager go haywire. crappy broken thing.
let me learn a bit more about hotkeys first

[Andreas Moog (ampelbein)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

[matejcik (matejcik)]

hello,
actually, i can't really tell - i have fixed this on my machine, perhaps not in the best possible way, but the kernel log is no longer spammed with the messages, which was the original problem.
and it appears that official hotkey-setup is still unchanged, so that would be a no.

i am going to test Intrepid Alpha 5 as soon as it comes out, so i'll get back to this bug.

[matejcik (matejcik)]

hi, i am running latest Intrepid now and the problem persists, in a way - all keys work as supposed (except for WiFi kill switch, but i assume that is a problem unrelated to hotkey-setup), but they generate noise in dmesg

i didn't yet manage to learn more about hotkey-setup, so i'd appreciate if somebody experienced had a look at this and perhaps made the fix ... althought pointing me to the relevant docs will do the trick too ;e)

[Steve Langasek (vorlon)]

The only documentation I can point you to on this is <https://wiki.ubuntu.com/Hotkeys/Troubleshooting>, which I'm not sure tells you anything you don't already know; and I don't have access to one of these laptops to reproduce the behavior you're describing. What is the noise generated in dmesg for these keys?

[Martin Pitt (pitti)]

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. Thanks!

[Martin Pitt (pitti)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[matejcik (matejcik)]

well sorry i don't have time to always have the latest-and-greatest ubuntu installed :ep

anyway.
restating the issue:
all special function keys work as expected, but they generate "unknown keycode" noise in dmesg. when attempting to fix the noise by including keys in a hotkey map, gnome brightness settings go haywire.

therefore, the troubleshooting steps don't really apply (as the keys do work)

from what i can tell, the problem is that the keys in question are sent both as an acpi event, seen by acpi_listen like this:
video DD04 00000087 00000000
video DD04 00000086 00000000
and as a key event, reported by kernel like this:
[ 1296.600041] atkbd.c: Unknown key pressed (translated set 2, code 0xf7 on isa0060/serio0).
[ 1296.600046] atkbd.c: Use 'setkeycodes e077 <keycode>' to make it known.
[ 1296.600962] atkbd.c: Unknown key released (translated set 2, code 0xf7 on isa0060/serio0).
[ 1296.600966] atkbd.c: Use 'setkeycodes e077 <keycode>' to make it known.
[ 1296.980697] atkbd.c: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0).
[ 1296.980702] atkbd.c: Use 'setkeycodes e078 <keycode>' to make it known.
[ 1296.981615] atkbd.c: Unknown key released (translated set 2, code 0xf8 on isa0060/serio0).
[ 1296.981618] atkbd.c: Use 'setkeycodes e078 <keycode>' to make it known.

the keys register in xev output properly:
KeyPress event, serial 31, synthetic NO, window 0x2800001,
    root 0x10b, subw 0x0, time 1609238, (352,590), root:(359,643),
    state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

also, setting brightness works independent of gnome-power-manager (which is good and please don't "fix" this ;e) )

this is with the keys not in the keymap. i'll try to test what happens with a proper keymap

[Steve Langasek (vorlon)]

The log output is:

[ 1346.397356] atkbd.c: Unknown key released (translated set 2, code 0xf7 on isa0060/serio0).
[ 1346.397359] atkbd.c: Use 'setkeycodes e077 <keycode>' to make it known.
[ 1346.552737] atkbd.c: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0).
[ 1346.552741] atkbd.c: Use 'setkeycodes e078 <keycode>' to make it known.

These are known to be supported in karmic (/lib/udev/keymaps/micro-star), and are most likely supported in Ubuntu 9.04 also.

The ACPI events match those handled by the /etc/acpi/events/video_brightness{down,up} hooks in acpi-support.
I'll pull those out of the package for karmic, to avoid the duplicate events.

[Martin Pitt (pitti)]

Ah, do the brightness keys stop working if you purge the acpi-support package? That still has a script to handle the acpi event. But I'd rather have it in udev properly, since acpi-support is destined to go away, and other models already generate proper brightness key input events (which causes double events for them).

e077 was brightness up, e078 was brightness down? Or the other way around?

Thanks!

[matejcik (matejcik)]

087 is down, 077 is up.
the file /lib/udev/keymaps has correct mappings, it just needs to be enabled in 95-keymap.rules (my DMI_VENDOR is Micro-Star, not MICRO-STAR)

now everything works, except when the brightness is minimum and i press Brightness down, the brightness starts blinking rapidly. this also happens on first run when gdm is started - and in there, it seems to stop when i click the mouse. when this happens in gnome session, only remedy is to set brightness to some normal level in some other way, e.g. through brightness applet.

so far it seems that without acpi-support, the behavior is good, let me reboot to test it

[Launchpad Janitor (janitor)]

This bug was fixed in the package acpi-support - 0.126

---------------
acpi-support (0.126) karmic; urgency=low

  * Drop /etc/acpi/start.d/10-save-dmidecode.sh, which is irrelevant given
    the existence of /sys/class/dmi/id/.
  * Drop events/panasonic-brightness-{down,up}, events/panasonic-mute,
    events/panasonic-volume-{down,up}, and panabright.sh, confirmed to be
    implemented now by the panasonic-laptop kernel driver.
  * Drop events/asus-{a6u-touchpad,internet,lock,wireless} and
    events/asus-media-{next,play-pause,prev,stop}, confirmed to be
    implemented by the asus-laptop kernel driver.
  * Drop events/thinkpad-thinkpad and thinkpad-thinkpad.sh, which is also
    implemented in the thinkpad_acpi driver and should have been dropped a
    while ago.
  * Drop /etc/acpi/{ac,battery}.d, which were still being installed.
  * Drop panapower.sh, which seems to have never been used.
  * Clean up /etc/acpi/toshbright.sh, which was meant to be removed back in
    jaunty
  * Clean up /etc/acpi/hibernatebtn.sh, no longer used.
  * Clean up /etc/acpi/wireless.sh, unused since before hardy.
  * debian/preinst: fix the rm_conffile script to correctly handle conffiles
    whose filename is a substring of another conffile in the same package
  * Drop events/video_brightness{down,up}, video_brightness{up,down}.sh: at
    least some platforms that use these ACPI sequences are seeing them
    correctly translated to input events, so those users will see duplicate
    events unless we drop them. LP: #178860.
  * Add missing dh_shlibdeps call to debian/rules.

 -- Steve Langasek <email address hidden> Wed, 26 Aug 2009 08:59:55 -0700

[matejcik (matejcik)]

so. without acpi-support, i can still see the keypresses through acpi_listen, everything still works as before and gnome can still be convinced to start blinking (by pressing brightness down repeatedly) - but that is now much harder to trigger (and from the looks of it, it's a different bug)

i'll try to remove the udev keymap and see if the keys still work

interestingly, i never saw that one keypress would skip two brightness levels (that's what i would expect if the events really came in twice) - so either they didn't, or gnome-power-manager is doing some magic and filtering the duplicates

[Steve Langasek (vorlon)]

reopen a udev task for the DMI_VENDOR case issue.

[matejcik (matejcik)]

ha! got something

if the udev keymap is disabled, the keys work as expected without problems.
they show up in acpi_listen and dmesg output as shown above.
and when i kill gnome-power-manager, they also show in xev output (using the command from Hotkeys/Troubleshooting) - twice:
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
both on keydown, nothing on keyup.

if the udev keymap is enabled, the keys don't show up in dmesg output. they do still show up in acpi_listen. also in xev - but now four times!
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0

when we hit lowest possible brightness, something interesting happens: single press of the BrightnessDown key generates this:
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0

or, in rare cases, this:
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0

this doesn't seem to depend on whether acpid is running:
matejcik@limetka:/etc/acpi$ ps ax | grep acpi
  166 ? S< 0:00 [kacpid]
  167 ? S< 0:00 [kacpi_notify]
  168 ? S< 0:00 [kacpi_hotplug]
 4886 pts/1 R+ 0:00 grep acpi
(i also killed hald-addon-acpi, just to be on the safe side)

brightness levels still go by one, with and without gnome-power-manager
so now i'm thoroughly confused.

oh, and when i change brightness on system boot, it works, but types "^@^@" into the console. once the system is up, this doesn't happen

the troubleshooting page says that "if there are too many keypress events then you need to determine where they are being duplicated." but doesn't elaborate much on that.

so what now?

[Martin Pitt (pitti)]

Steve,

wow, I was about to ask you whether to drop video_brightness* scripts, and there you are and have done it already. Many thanks!

udev rule fixed upstream in http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=66bf63c

[Martin Pitt (pitti)]

> if the udev keymap is disabled, the keys work as expected without problems. they show up in acpi_listen and dmesg output as shown above.

That's all with acpi-support purged? It's probably that your brightness keys are hardwired and directly control the brightness in hardware. Then the key events are merely used to giving visual feedback (the notification bubbles which show the percentage).

> when we hit lowest possible brightness, something interesting happens: single press of the BrightnessDown key generates this:

If you already purged acpi-support and stopped acpid, then it's not that any more, so for some reason the kernel duplicates these input events. It looks like the udev mapping is not actually required, and the default kernel already provides the correct key codes itself. But then setting the same values again in udev shouldn't really change things.

So this effect seems to be an independent problem in the kernel, as far as I can see.

[matejcik (matejcik)]

no, the keys aren't hardwired, there are still situations where they don't work. that's in grub menu, i think, and also there were bugs in some older ubuntu releases that they didn't work until g-p-m started

so, is it normal that the key sends the event twice?

and if it is a kernel bug, where to report it and how to debug it?

[Steve Langasek (vorlon)]

It can't be an issue with a hardwired key, since we're seeing X keypress events. Something has to be passing those up to X from the kernel.

With acpid stopped and the udev rule disabled (as confirmed in the output of /lib/udev/keymap input/event5 | grep 'f[78]'), what do you see as output when attaching to the input device with either 'sudo /lib/udev/keymap -i input/event5' or 'sudo input-events 5' at the console, and pressing the hotkeys? And if you do the same with input/event6 instead?

[Martin Pitt (pitti)]

matejcik [2009-08-26 17:43 -0000]:
> no, the keys aren't hardwired, there are still situations where they
> don't work.

Hm, interesting. So just to confirm, without the udev rule (after a
clean boot, so that the keymap is really reset), and acpid stopped you
still get the correct keys in xev? That's really a kind of magic. I
checked your lsinput and udev db dump, and there's no other magic
input device where they could come from.

> so, is it normal that the key sends the event twice?

No, that's a bug. I suppose enabling them in acpi-support or udev
makes them work the proper way, and then there's the "magic way" from
above which we didn't understand yet.

> and if it is a kernel bug, where to report it and how to debug it?

Reporting can be done here (I opened a linux task), but right now I'm
afraid I don't know how to debug it either. :-(

[matejcik (matejcik)]

with stock udev (without the rule to load micro-star keymap) and acpid stopped, i still have two key events from xev, as said above

in that situation:
matejcik@limetka:~$ sudo /lib/udev/keymap input/event5 | grep 'f[78]'
0x041 f7
0x042 f8
0x0f7 reserved
0x0f8 reserved
0x1f7 reserved
0x1f8 reserved

for the following, i'm always pressing fn+f4 (brightness down) once and after that fn+f5 (brightness up) once.

"/lib/udev/keymap -i input/event5" gives nothing
(in non-X console, it also emits the "unknown keycode" kernel messages and a single "^@" - which leads me to believe that the ^@ is eaten by bash and that's why i don't see it after login; the kernel mesages are displayed whenever i press the key, not just with this command)

input/event6 gives:
scan code: 0x00 key code: brightnessdown
scan code: 0x00 key code: brightnessup
(which is true ;e) )

input-events 5 gives:
22:01:30.610733: EV_MSC code=4 value=247
22:01:30.610769: EV_SYN code=0 value=0
22:01:30.611648: EV_MSC code=4 value=247
22:01:30.611675: EV_SYN code=0 value=0
22:01:32.687762: EV_MSC code=4 value=248
22:01:32.687794: EV_SYN code=0 value=0
22:01:32.688687: EV_MSC code=4 value=248
22:01:32.688713: EV_SYN code=0 value=0
(that's twice the same output for each keypress)

input-events 6 gives:
22:02:03.536339: EV_KEY KEY_BRIGHTNESSDOWN (0xe0) pressed
22:02:03.536356: EV_SYN code=0 value=0
22:02:03.536361: EV_KEY KEY_BRIGHTNESSDOWN (0xe0) released
22:02:03.536365: EV_SYN code=0 value=0
22:02:04.837748: EV_KEY KEY_BRIGHTNESSUP (0xe1) pressed
22:02:04.837762: EV_SYN code=0 value=0
22:02:04.837766: EV_KEY KEY_BRIGHTNESSUP (0xe1) released
22:02:04.837769: EV_SYN code=0 value=0
(both "pressed" and "released" come up simultaneously, regardless of actual keydown/keyup)

[Steve Langasek (vorlon)]

Interesting, that means these key events are coming across the "Video Bus" input device.
 [...]
 /dev/input/event6
   bustype : BUS_HOST
   vendor : 0x0
   product : 0x6
   version : 0
   name : "Video Bus"
   phys : "/video/input0"
   bits ev : EV_SYN EV_KEY
 [...]

Martin, I think this means the udev change should probably be reverted, since we *don't* want to map these keys a second time. And yes, there's definitely a kernel bug here, since the kernel should only make these events show up on one input device or the other - not on both.

[Martin Pitt (pitti)]

Right, reverted upstream in commit bc19bff.

[matejcik (matejcik)]

On Wed, Aug 26, 2009 at 22:25, Steve Langasek
<email address hidden>wrote:

> Martin, I think this means the udev change should probably be reverted,
> since we *don't* want to map these keys a second time.

please bear in mind that there are other keys in the mapping: wifi toggle,
bluetooth toggle, touchpad toggle, webcam toggle (and maybe external display
key, i didn't check that). those also generate dmesg noise but work anyway.
my guess is that those -are- hardwired to their respective functions in some
way, because they seem to work everywhere. also, the bt/wifi is a single key
and depending on bios version, it either toggles wifi and bt simultaneously,
or cycles between both off -> wifi on -> bt on -> both on, generating the
appropriate keypresses every time and switching the status leds.

brightness keys are the only ones producing actual measurable trouble, but
the others are acting weird too.

[Steve Langasek (vorlon)]

Just to be sure we know what we're looking at, could you run 'sudo /lib/udev/findkeyboards' and 'sudo /lib/udev/keymap input/event6'?

BTW, maybe this goes without saying, but the input device numbers are not static; they can be different across every reboot. So perhaps we should re-check the output of 'lsinput' as well.

[matejcik (matejcik)]

matejcik@limetka:~$ sudo /lib/udev/findkeyboards
AT keyboard: input/event5
matejcik@limetka:~$ sudo /lib/udev/keymap input/event6
### evdev 1.0.0., driver 'Video Bus'
matejcik@limetka:~$ sudo /lib/udev/keymap input/event5
### evdev 1.0.0., driver 'AT Translated Set 2 keyboard'

which seems to be the same across reboots, and it's definitely the same as it was in comment #26;
diff from the lsinput.log posted here only reveals that i have disconnected the logitech usb mouse in the meantime ;e)

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Andy Whitcroft (apw)]

Could we confirm that this issue still exists in current releases. The latest testing seems pretty old, indeed on releases now off support. Thanks in advance!

[matejcik (matejcik)]

yes, the same problem still exists in Maverick and Natty alpha

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.