Hotkeys stopped functioning - Dell Inspiron 1420

[Harvey Muller]

This report is relative to Ubuntu Intrepid Beta amd64 desktop. They previously worked in Gutsy and Hardy.

The hotkeys that have stopped functioning are:

    Fn-F1 - Hibernate
    Fn-F3 - Power Information
    Fn-F10 - Optical Disk Eject

When each key combination is depressed, a KeyRelease is generated multiple times in rapid succession and does not stop until the Esc key is depressed.

These are the results for each key combination:

Fn-F1
KeyRelease event, serial 34, synthetic NO, window 0x3c00001,
    root 0x13b, subw 0x0, time 1634554, (1010,182), root:(1017,233),
    state 0x0, keycode 213 (keysym 0x1008ff10, XF86Standby), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Fn-F3
KeyRelease event, serial 34, synthetic NO, window 0x3c00001,
    root 0x13b, subw 0x0, time 1891082, (1246,317), root:(1253,368),
    state 0x0, keycode 244 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Fn-F10
KeyRelease event, serial 34, synthetic NO, window 0x3c00001,
    root 0x13b, subw 0x0, time 1934885, (1074,187), root:(1081,238),
    state 0x0, keycode 170 (keysym 0x1008ff2c, XF86Eject), same_screen YES,
    XKeysymToKeycode returns keycode: 169
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

laptop identification strings using `sudo dmidecode -s ...`:

system-manufacturer: Dell Inc.
system-product-name: Inspiron 1420
system-version: Not Specified

[Chris Coulson (chrisccoulson)]

Thanks for the bug report Harvey. Do you mean that these keys no longer trigger the events that they are meant to do (eg, Fn-F1 no longer hibernates etc)? I think these are meant to generate ACPI events. Could you please run 'acpi_listen' in a terminal and press the keys which don't work. Do you see any output? If so, could you please post it here?

Could you also attach the output of 'sudo dmidecode'? Thanks in advance.

[Harvey Muller (hlmuller)]

Chris,

I forgot to mention that. acpi_listen does not report any acpi events when any of the key combinations mentioned are depressed. acpi_listen does report the power button acpi_event, so acpi_listen is working.

Thanks,

Harvey

p.s. I am running with the latest updates.

[Chris Coulson (chrisccoulson)]

Thanks. This does seem to be a kernel problem then. Would you be able to try running acpi_listen on a known working live CD, just to be sure that those keys do generate ACPI events?

[Harvey Muller (hlmuller)]

Chris,

I can confirm that acpi_listen does NOT report any ACPI events when any of the 3 key combinations are depressed using a known good live cd. The live cd used for this test is Monday's Ubuntu Intrepid Beta amd64 desktop daily-live from cdimage.ubuntu.com.

I also failed to mention an observation: When running `xev | grep -A5 KeyRelease` in a terminal, each of the key combinations produces multiple key releases, similar to a race condition. Pressing the Esc key stops the key release events from being generated.

Hope that helps,

Harv

[Chris Coulson (chrisccoulson)]

Ah, thanks for trying that. That means that these keys aren't actually meant to generate ACPI events, so the problem probably isnt with the kernel. I'll take a look at this again later when I get home from work.

[Harvey Muller (hlmuller)]

No problem, I like troubleshooting. I created a separate bug #278658 for a dedicated hotkey. I did not want to confuse any issues by including it, but you might consider it a duplicate of this one. I leave that to your judgement.

[Chris Coulson (chrisccoulson)]

Harvey,

Please could you to attach the output of 'lshal', and also attach your /var/log/Xorg.0.log file.

Thanks

[Harvey Muller (hlmuller)]

Here you go Chris

[Angelo Bernardi (anbernardi)]

I'm having the same issues in Intrepid i686 on the same machine

I've posted some details in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/278658

[Chris Coulson (chrisccoulson)]

I'm a little confused about the multiple key releases, and I don't know if it is related or not. As Mario requested in the other bug report, it would be good for you to kill gnome-settings-daemon and then run xev, to see if you see the hotkeys in xev.

Thanks

[Chris Coulson (chrisccoulson)]

Actually, in this case, you will probably need to killall gnome-power-manager

[Harvey Muller (hlmuller)]

Chris,

`killall gnome-power-manager` results in single (and not multiple as originally reported):

Fn-F1:
KeyRelease event, serial 34, synthetic NO, window 0x2e00001,
    root 0x13b, subw 0x2e00002, time 471252, (32,33), root:(1043,724),
    state 0x0, keycode 67 (keysym 0xffbe, F1), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Fn-F3
KeyRelease event, serial 34, synthetic NO, window 0x2e00001,
    root 0x13b, subw 0x2e00002, time 475331, (32,33), root:(1043,724),
    state 0x0, keycode 69 (keysym 0xffc0, F3), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Fn-F10
KeyRelease event, serial 34, synthetic NO, window 0x2e00001,
    root 0x13b, subw 0x2e00002, time 482320, (32,33), root:(1043,724),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

I'll reboot and see if there is any difference with killing gnome-settings-daemon.

Thanks,

Harv

[Harvey Muller (hlmuller)]

Chris,

`killall gnome-settings-daemon` has the same effect. The key releases are generated but not as multiple repeating events as observed in the original report.

KeyRelease event, serial 33, synthetic NO, window 0x1a00001,
    root 0x13b, subw 0x1a00002, time 175803, (51,43), root:(1062,732),
    state 0x0, keycode 67 (keysym 0xffbe, F1), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

--
KeyRelease event, serial 33, synthetic NO, window 0x1a00001,
    root 0x13b, subw 0x1a00002, time 186995, (51,44), root:(1062,733),
    state 0x0, keycode 69 (keysym 0xffc0, F3), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

--
KeyRelease event, serial 33, synthetic NO, window 0x1a00001,
    root 0x13b, subw 0x1a00002, time 189178, (51,44), root:(1062,733),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Thanks,

Harv

[Chris Coulson (chrisccoulson)]

Harvey - Sorry for not responding quicker. Those last keypresses look odd, as they are just F1, F3 and F10 symbols.

Do your other hotkeys work (in particular, your volume keys)? If they do, could you obtain an output from xev with these keys, both with and without gnome-settings-daemon running (and note whether you see the multiple key release events - it might indicate if it is a red herring or not).

Thanks

[Harvey Muller (hlmuller)]

Hi Chris,

No problem. All the dedicated hotkeys work out of the box, except the stop playback key but it is reported separately (identified above)

The hotkeys to not emit key releases using xev.

When gnome-settings-daemon is killed, however, they do. These are the key releases generated under that circumstance:

KeyRelease event, serial 33, synthetic NO, window 0x2600001,
    root 0x13b, subw 0x2600002, time 533090, (58,34), root:(1069,725),
    state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x2600001,
    root 0x13b, subw 0x2600002, time 538704, (58,34), root:(1069,725),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x2600001,
    root 0x13b, subw 0x2600002, time 543411, (58,34), root:(1069,725),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Hope that helps,

Harv

[Harvey Muller (hlmuller)]

Changing status based on Angelo's input

[Chris Coulson (chrisccoulson)]

Harvey,

Would you mind running the following:

killall gnome-power-manager
gnome-power-manager --no-daemon --verbose 2>&1 gpm.log

...and then attaching gpm.log. I wonder if GPM is not grabbing the keys. Other than that, I'm a bit confused. I might have to ask someone to help me out here;)

[Chris Coulson (chrisccoulson)]

Right, I think I've just answered my own question.

Looking at the g-p-m source, it is grabbing XF86XK_Sleep, which is keysym 0x1008FF2F according to X11/XF86keysym.h. Your Fn+F1 is translated to a keysym of 0x1008ff10 (or XF86XK_Standby), which is not what g-p-m is grabbing as the sleep button (or at least I think not).

I think the log you provide will confirm that. The same probably applies to the other keys. I still don't really know which package is responsible though.

[Harvey Muller (hlmuller)]

Chris,

I'm getting ready to head home, and will provide the log when I get there. Thanks for puzzling it out so far. I've spent days learning about keyboard interaction in both the console and in X, and was getting ready to learn about the gnome interaction.

I'll provide the requested information then.

Thanks again,

Harv

[Harvey Muller (hlmuller)]

The requested data is attached.

[Chris Coulson (chrisccoulson)]

Thanks. As suspected, GPM does not grab keycode 213, which is the event coming from your suspend key. That explains why Fn+F1 doesn't work. However, GPM has never grabbed that key (or at least it didn't in Hardy), so I don't think that this is the fault of GPM.

Could you switch to a terminal (CTRL+ALT+F1), and try the following:

Run "sudo /etc/init.d/hotkey-setup stop" and then "showkey -s". Press the Fn+F1 combination and note the scancodes. Now run "showkey -k" and press the same key combination again, noting the keycodes that appear.

Then could you run "sudo /etc/init.d/hotkey-setup start", and repeat the above test with "showkey -k" and "showkey -s".

When you run "showkey -s", scancodes will appear for both press and release. It might be useful if you could annotate the output so I know where you pressed and released keys.

Thanks

[Harvey Muller (hlmuller)]

Chris,

As requested:

sudo /etc/init.d/hotkey-setup stop
----------------------------------

kb mode was UNICODE
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
0x9c
*** Fn-F1 Pressed Here ***
kb mode was UNICODE
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
keycode 28 release
*** Fn-F1 Pressed Here ***

sudo /etc/init.d/hotkey-setup start
-----------------------------------

kb mode was UNICODE
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
0x9c
*** Fn-F1 Pressed Here ***
0xe0 0x25
kb mode was UNICODE
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
keycode 28 release
*** Fn-F1 Pressed Here ***
keycode 205 press

HTH,

Harv

[Chris Coulson (chrisccoulson)]

Harvey,

If you do the following:

sudo setkeycodes e025 150

Does Fn+F1 work correctly?

Could you also provide the output from "sudo showkey -s" and "sudo showkey -k" for your other non-working keys?

Thanks

[Chris Coulson (chrisccoulson)]

Whoops!

I made a mistake in my last comment. I meant:

sudo setkeycodes e025 142

150 will launch a web browser. D'oh!

[Chris Coulson (chrisccoulson)]

Actually, that probably won't work at all, as the key is already mapped. Still, the output of "sudo showkey -s" and "sudo showkey -k" would be useful for the other non-working keys

[Harvey Muller (hlmuller)]

Chris,

I'll provide the info on the other keys in a few minutes. But I'll confirm that `sudo setkeycodes e025 150` does result in proper hibernation.

Thanks,

Harv

[Harvey Muller (hlmuller)]

Chris,

The last comment was noise. I was in my Hardy partition and not in the Intrepid partition. The Fn-F1 key combo in Hardy still hibernated using `sudo setkeycodes e025 150`, but does not in Intrepid. Changing 150 to 142 in Intrepid does not result in the proper action either.

Sorry,

Harv

[Chris Coulson (chrisccoulson)]

I didn't think it would work.

It seems obvious now that the FN+F1 hot key doesn't work because nothing is grabbing the key. FN+F10 seems to be something similar, but that should normally be grabbed by gnome-settings-daemon, and is user configurable. What is the output of:

"gconftool-2 --get /apps/gnome_settings_daemon/keybindings/eject"

Your FN+F3 combination is a bit wierd. The xkeycode seems to map to a null xkeysym. It would be interesting to see the kernel keycode for this combination. Could you please try running "sudo showkey -k" in a terminal (CTRL+ALT+F1), and post the output when you press FN+F3.

I think there could be multiple issues here.

Thanks

[OliFre (freyermuth)]

I have a Vostro 1500 and the same problems.
"gconftool-2 --get /apps/gnome_settings_daemon/keybindings/eject"
gives me
XF86Eject
and
sudo showkey -k
returns:
(FN+F1) keycode 205 press
(FN+F3) keycode 236 press
(FN+F10) keycode 162 press
Worked fine in Hardy before, though.

[pauls (paulatgm)]

FWIW, I have the same problem with the same Fn keys when I install intrepid. I have a Dell E1505 laptop. Maybe this problem is all Dells!

regards,

[DrFaNaTiC (drfanatic)]

Same here, Dell Inspiron 6400. The command "acpi_listen" says nothing for this Keys.

Linux dell 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux
Intrepd Ibex 8.10

Thanks,
drfanatic

[Chris Coulson (chrisccoulson)]

Sorry for the delay with this. You are experiencing multiple issues with your hotkeys (I think).

The eject key is most likely related to bug 299194. There is a fix in intrepid-proposed for this. It would be great if you could test this.

The battery key is probably related to bug 281134, which is now fixed in Jaunty.

I think the hibernate key is a bug in gnome-power-manager, because it does not grab XF86Standby, so I'll re-assign to gnome-power-manager for that.

[Steve Beattie (sbeattie)]

This bug was reported in the Intrepid development cycle; removing regression-potential and marking as regression-release.

[Scott Howard (showard314)]

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 if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

(setting to incomplete so I know to check it later, if it exists in Karmic, set back to triaged. If it doesn't exist in Karmic then this would be set to "invalid" since this bug won't be eligible for an SRU and backporting won't work since HAL has been removed in favor of devicekit-power).

[xteejx (xteejx-deactivatedaccount)]

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!