Bug 757937

Summary: HP HDX 9494NR: fn brightness keys not working
Product: [Fedora] Fedora Reporter: David <dahmage>
Component: udevAssignee: udev-maint
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: aaron.lwe, harald, jonathan, martin.pitt, udev-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-05 06:52:36 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description David 2011-11-28 21:50:03 EST
My HP HDX 9494NR laptop has brightness up and down as fn keys (fn + f7 is brighnessdown and fn + f8 is brightness up).  When i press either of these buttons nothing happens, but i get the following in dmesg:

atkbd serio0: Unknown key pressed (translated set 2, code 0x81 on isa0060/serio0).
atkbd serio0: Use 'setkeycodes e001 <keycode>' to make it known.
atkbd serio0: Unknown key pressed (translated set 2, code 0x81 on isa0060/serio0).
atkbd serio0: Use 'setkeycodes e001 <keycode>' to make it known.

The first two messages relate to fn+f7, and the second two relate to fn+f8.

I can manually adjust the brightness (from 0 to 10) by echoing values directy into /sys/class/backlight/acpi_video0/brightness


Please let me know what additional information you need and i will do my best
to get it for you.
Comment 1 Aaron Lu 2011-12-28 01:57:23 EST
Same here, mine is HP ProBook 6455b.

When I press Fn+F9(brightness down), an icon will appear and indicates the level is down but the actual backlight is not affected. Additional hits of the combined key has no effect on the icon shown(no more indications of the levels down) and the backlight is still not adjusted.

And echo to /sys/class/backlight/acpi_video/brightness also works for me.

The original LiveCD works, after the install I did a yum update, many packages(including kernel package) get updated and now the Fn key does not work anymore.
Comment 2 Harald Hoyer 2012-01-05 05:30:23 EST
(In reply to comment #0)
> My HP HDX 9494NR laptop has brightness up and down as fn keys (fn + f7 is
> brighnessdown and fn + f8 is brightness up).  When i press either of these
> buttons nothing happens, but i get the following in dmesg:
> 
> atkbd serio0: Unknown key pressed (translated set 2, code 0x81 on
> isa0060/serio0).
> atkbd serio0: Use 'setkeycodes e001 <keycode>' to make it known.
> atkbd serio0: Unknown key pressed (translated set 2, code 0x81 on
> isa0060/serio0).
> atkbd serio0: Use 'setkeycodes e001 <keycode>' to make it known.
> 
> The first two messages relate to fn+f7, and the second two relate to fn+f8.
> 
> I can manually adjust the brightness (from 0 to 10) by echoing values directy
> into /sys/class/backlight/acpi_video0/brightness
> 
> 
> Please let me know what additional information you need and i will do my best
> to get it for you.

Please follow the instructions in
/usr/share/doc/udev-*/README.keymap.txt
Comment 3 Harald Hoyer 2012-01-05 05:32:01 EST
(In reply to comment #1)
> Same here, mine is HP ProBook 6455b.
> 
> When I press Fn+F9(brightness down), an icon will appear and indicates the
> level is down but the actual backlight is not affected. Additional hits of the
> combined key has no effect on the icon shown(no more indications of the levels
> down) and the backlight is still not adjusted.
> 
> And echo to /sys/class/backlight/acpi_video/brightness also works for me.
> 
> The original LiveCD works, after the install I did a yum update, many
> packages(including kernel package) get updated and now the Fn key does not work
> anymore.

If the icon appears, open a bug against gnome-power-manager
Comment 4 Fedora End Of Life 2013-01-16 15:35:10 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Martin Pitt 2013-01-25 05:45:26 EST
(In reply to comment #0)
> atkbd serio0: Unknown key pressed (translated set 2, code 0x81 on
> isa0060/serio0).
> atkbd serio0: Use 'setkeycodes e001 <keycode>' to make it known.
> atkbd serio0: Unknown key pressed (translated set 2, code 0x81 on
> isa0060/serio0).
> atkbd serio0: Use 'setkeycodes e001 <keycode>' to make it known.
> 
> The first two messages relate to fn+f7, and the second two relate to fn+f8.

Are you sure that you pressed these two? The two sets of messages are exactly the same. Perhaps a wrong copy&paste? Can you please try this again and tell me which is Fn+F7, and which is Fn+F8?

Thank you!
Comment 6 Martin Pitt 2013-01-25 05:46:46 EST
For the record: DMI data for this machine is in bug 757928.
Comment 7 David 2013-01-27 13:52:59 EST
(In reply to comment #5)
> (In reply to comment #0)
> > atkbd serio0: Unknown key pressed (translated set 2, code 0x81 on
> > isa0060/serio0).
> > atkbd serio0: Use 'setkeycodes e001 <keycode>' to make it known.
> > atkbd serio0: Unknown key pressed (translated set 2, code 0x81 on
> > isa0060/serio0).
> > atkbd serio0: Use 'setkeycodes e001 <keycode>' to make it known.
> > 
> > The first two messages relate to fn+f7, and the second two relate to fn+f8.
> 
> Are you sure that you pressed these two? The two sets of messages are
> exactly the same. Perhaps a wrong copy&paste? Can you please try this again
> and tell me which is Fn+F7, and which is Fn+F8?
> 
> Thank you!

Yes i am sure that was right, i remember thinking that it was odd that the same data was generated for the different key presses, so i verified it several times.

I went to verify this again just now on F18, and i no longer see any messages in dmesg.  Where should i look now to see what is happening?  (brightness up and down still have no affect on the system, even with the messages gone from dmesg)

Thanks for your help
Comment 8 David 2013-01-27 16:37:09 EST
If i run showkey as root i see the following:

when i press fn+f7: keycode 465 press
when i press fn_f8: keycode 465 press


yes it is the same keycode value! could this be a result of there being no release event?
Comment 9 Martin Pitt 2013-01-28 01:44:57 EST
> yes it is the same keycode value! could this be a result of there being no release event?

This just shows that the kernel default is wrong and it assigns the same keycode ("meaning") to two different scancodes (the hardware "numbering" of the keys). Can you please try this again with "keymap -i" as described in /usr/share/doc/udev-*/README.keymap.txt ?

Thanks!
Comment 10 David 2013-01-28 08:43:23 EST
/usr/share/doc/udev-*/README.keymap.txt doesn't exist, but /usr/share/doc/systemd/README.keymap.txt does.

it looks like several other keys are not mapped correctly, but the console window keeps scrolling past everything very quickly, is that expected?  (it is as if something is sending line breaks constantly).
Comment 11 David 2013-01-28 09:11:58 EST
after waiting for some time the terminal stopped scrolling and i was able to capture all of the fn keys.  here is each key [and what it is labeled as] followed by the keymap -i output

there are some oddities:
- presing fn+f2 generated two scan codes
- print screen and sys rq are both showing up as keycode sysrq, but in practice they both result in taking a screen shot?



fn+f1 [?]
scan code: 0x81   key code: fn_esc

fn+f2 [Print]
scan code: 0x1D   key code: leftctrl
scan code: 0x19   key code: p

fn+f3 [www}
scan code: 0xB2   key code: www

fn+f4 [input]
scan code: 0x81   key code: fn_esc

fn+f5 [sleep]
scan code: 0xDF   key code: sleep

fn+f6 [lock]
scan code: 0x81   key code: fn_esc

fn+f7 [brigness down]
scan code: 0x81   key code: fn_esc

fn+f8 [brightness up]
scan code: 0x81   key code: fn_esc

fn+f9 [play/pause]
scan code: 0xA2   key code: playpause

fn+f10 [stop]
scan code: 0xA4   key code: stopcd

fn+f11 [previoustrack]
scan code: 0x90   key code: previoussong

fn+f12 [nexttrack]
scan code: 0x99   key code: nextsong

fn+insert [scrolllock]
scan code: 0x46   key code: scrolllock

fn+home [print screen]
scan code: 0xB7   key code: sysrq

fn+end [sys rq]
scan code: 0x54   key code: sysrq

fn+pgup [pause]
scan code: 0xC5   key code: pause

fn+pgdn [break]
scan code: 0xC6   key code: pause
Comment 12 Martin Pitt 2013-01-28 11:17:52 EST
Thanks for that list. It seems that there are five keys which all send the same scan code 0x81, which is either a bug in the HP's firmware or perhaps the kernel driver for its input module. I'm afraid we can't fix that with udev keymaps.
Comment 13 David 2013-01-28 11:40:20 EST
(In reply to comment #12)
> Thanks for that list. It seems that there are five keys which all send the
> same scan code 0x81, which is either a bug in the HP's firmware or perhaps
> the kernel driver for its input module. I'm afraid we can't fix that with
> udev keymaps.

Do you know where i should start looking in regards to the kernel driver?  I would like to fix this if at all possible, but i understand your point that udev mapping can't fix wrong scan codes.

It looks like the duplicate sysrq and pause keys can be fixed however.  I am bit confused by the fact that both print screen and sysrq keys are mapped to sysrq, but in practice in gnome shell both of the trigger print screen?
Comment 14 David 2013-01-28 16:22:01 EST
Also for the record, i can no longer manually adjust the brightness (from 0 to 10) by echoing values directy into /sys/class/backlight/acpi_video0/brightness

I haven't tested this since Fedora 16 so i don't know when it stopped working.
Comment 15 Martin Pitt 2013-01-29 05:41:16 EST
(In reply to comment #13)
> Do you know where i should start looking in regards to the kernel driver?

I'm sorry, I don't. I hope a kernel-ish person can chime in and answer this.
Comment 16 Martin Pitt 2013-01-29 05:44:02 EST
(In reply to comment #14)
> Also for the record, i can no longer manually adjust the brightness (from 0
> to 10) by echoing values directy into
> /sys/class/backlight/acpi_video0/brightness

A more modern interface is XBacklight as far as I know (although I had expected this to eventually just poke values into sysfs as well). You can check

  xrandr --verbose|grep BACKLIGHT

whether this is supported in your system. In the screen settings of control-center you have a slider to manually set the backlight. If that works, then that part is okay, and just needs to be wired correctly with the keys.
Comment 17 David 2013-01-29 06:48:46 EST
(In reply to comment #16)
>   xrandr --verbose|grep BACKLIGHT

this outputs nothing.  i looked through the full output as well and didn't see backlight mentioned or anything similar


> whether this is supported in your system. In the screen settings of
> control-center you have a slider to manually set the backlight. If that
> works, then that part is okay, and just needs to be wired correctly with the
> keys.

Yes the slider works, and it adjusts the brightness as expected.
Comment 18 Fedora End Of Life 2013-12-21 03:31:20 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Fedora End Of Life 2014-02-05 06:52:39 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.