Bug 613599

Confirmed on my Asus UL50Vg, the brightness keys do not alter brightness. It used to work with Fedora 11, but not anymore. Brightness is probably not handled by Nouveau, as it doesn't work with Intel graphics anymore either (same notebook). Xev shows no response when pressing fn+f5 or fn+f6. I can alter brightness by writing a number to /proc/acpi/video/vga1/LCDD/brightness , but only as root. Even trying to write with sudo fails.

I would also like to take this oppertunity to note the fact that there is another function key not working. The key is supposed to toggle the touchpad on or off. Pressing it shows the following in xev:
KeyPress event, serial 35, synthetic NO, window 0x4800001,
    root 0x1d6, subw 0x0, time 3110158, (1022,31), root:(1025,97),
    state 0x10, keycode 191 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x4800001,
    root 0x1d6, subw 0x0, time 3110158, (1022,31), root:(1025,97),
    state 0x10, keycode 191 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
It does hoewever not do anything.

(In reply to comment #1)
> I would also like to take this oppertunity to note the fact that there is
> another function key not working.

Please, file a separate bug against xkeyboard-config component 

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)

Thanks in advance.

Actually, plase, attach these files here as well.

Thank you.

Comment on the touchpad on / off key not working. This might be because the Elantech touchpad is misdetected as a mouse, not a touchpad.

This bug is filed as:
https://bugzilla.redhat.com/show_bug.cgi?id=549065
https://bugzilla.redhat.com/show_bug.cgi?id=556229

I will give you something more interesting ;)

[roy@Torres drivers]$ acpi_listen 
hotkey ATKD 0000002e 00000003
hotkey ATKD 0000001f 00000004

This means that the keycode for newer Asus notebooks for KEY_BRIGHTNESSDOWN should be 0x2e, and for KEY_BRIGHTNESSUP it's 0x1f. I'd propose patching kernel/drivers/platform/x86/asus-laptop.c to reflect these (new?) keycodes. The 0x1f is currently mapped to KEY_BATTERY, and indeed when pressing the brightness up key, the powermanager pops up.

Hah, did some testing around with asus-laptop.c. It's actually slightly more complicated. keycode & 0xf0 == 20 means the brightness is lowered, keycode & 0x0f == 10 means brightness is up. keycode & 0x0f states the desired brightness level, from 0 to 15. So with brightness maxed out these keycodes are correct. However with brightness set to minimum the right keycodes become 0x20 and 0x11.

Created attachment 439692 [details]
Patch for newer brightness keys

This patch does the trick for me. It adds the new brightness keys as keycodes and test for Asus laptops with model ULxxV.

Created attachment 439698 [details]
Proper patch for fixing backlight buttons

Bugger... C has been too long ago for me, and two wrongs made a works-for-me. _This_ patch fixes the strncmp

(In reply to comment #8)
> Created attachment 439698 [details]
> Proper patch for fixing backlight buttons
> 
> Bugger... C has been too long ago for me, and two wrongs made a works-for-me.
> _This_ patch fixes the strncmp

Could you send this upstream?  It appears this still isn't fixed in the 3.x kernels.

(In reply to comment #9)
> (In reply to comment #8)
> > Created attachment 439698 [details]
> > Proper patch for fixing backlight buttons
> > 
> > Bugger... C has been too long ago for me, and two wrongs made a works-for-me.
> > _This_ patch fixes the strncmp
> 
> Could you send this upstream?  It appears this still isn't fixed in the 3.x
> kernels.

The original author refused this patch to go upstream, mostly because of the way the laptop model is determined (with strncmp). Unfortunately, I don't have a better way. The best fix would be adding GPU switching support for the mainline kernel, as the brightness keys do work when the graphics mode is set to hybrid in the BIOS setup utility. This workaround however would be greatly appreciated, as switching support is far from ready afaik.

On my Asus notebook (K93SV), the brightness keys are actually detected and I can see Gnome's brightness notification on Fedora 16 beta 2. However, the brightness does not change - either key will result in the notification panel showing up and displaying either of the two states shown in the attached screenshot.

Thus, the keyboard recognizing the keys properly may have been fixed (test in F16beta2 to verify?) but the hardware side still has problems.

I realize that this is a different notebook, but according to my experiences with bugs and semi-recent to recent Asus notebooks most bugs seem related to exactly the same things.

I can pretty much ensure you that these problems are not related. The problem I am encountering is a bug in the BIOS of this notebook (series) that only occurs when "hybrid graphics" (not to be confused with Optimus) is turned off in the BIOS setup utility. This hybrid graphics I am talking about is no longer being deployed on Asus notebooks.
I will nonetheless give Fedora a spin as soon as it's out, but I'm not getting my hopes up unless someone brought this patch in for Fedora.

Moving this to rawhide, as I still don't see anything upstream that would have fixed it.

Matthew, do you have any suggestions on how to proceed here?

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Is this still a problem with 3.9 based F19 kernels?

Don't know, I am running F18 with kernel 3.8.

I can however add the information that brightness keys are not working with hybrid graphics on (BIOS setting SATA = enhanced, no that is not intuitive) and bumblebee. Comment 12 as I understood it indicated that non-working brightness keys are related to running only dedicated graphics (BIOS setting SATA = compatibility).

(In reply to comment #15)
> Is this still a problem with 3.9 based F19 kernels?

No, with my current setup (with a 3.9 kernel from nouveau GIT and hybrid graphics disabled) the brightness keys work! \o/