Bug 757937

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.

(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

(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

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

(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!

For the record: DMI data for this machine is in bug 757928.

(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

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?

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

/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).

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

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.

(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?

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.

(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.

(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.

(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.

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.

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.