Created attachment 80791 [details]
lspci output

Created attachment 80801 [details]
dmesg output

I have exactly the same problem on Asus A8F laptop, Ubuntu, 32 bit, kernel
3.2.0-32-generic-pae. 

However, the asus_laptop module is loaded and running normally in my laptop. The brightness change is reflected in and changes together with /sys/class/backlight/asus_laptop/brightness value. But the Fn+F5/F6 keys do not produce any X event (tested using xev).

I will upgrade to Ubuntu 12.10 soon (presumably, it has a more up to date kernel) and test if the issue is still there, and will report it.

By the way, after doing modprobe -r asus-laptop I can still control the backlight using the Fn combinations, so it is not related to this kernel module.

Another note : it seems that the keypresses do get caught by acpi:

$acpi_listen
[starting from total bright: press Fn+F5]
hotkey ATKD 0000002e 00000023
hotkey ATKD 0000002d 0000001f
hotkey ATKD 0000002c 0000001e
hotkey ATKD 0000002b 0000001d
hotkey ATKD 0000002a 0000001b
hotkey ATKD 00000029 00000018
hotkey ATKD 00000028 00000017
hotkey ATKD 00000027 00000017
hotkey ATKD 00000026 00000017
hotkey ATKD 00000025 00000015
hotkey ATKD 00000024 00000016
hotkey ATKD 00000023 00000010
hotkey ATKD 00000022 0000000f
hotkey ATKD 00000021 0000000e
hotkey ATKD 00000020 00000055
[total dark now: press Fn+F6]
hotkey ATKD 00000011 0000000d
hotkey ATKD 00000012 0000000e
hotkey ATKD 00000013 0000000f
hotkey ATKD 00000014 00000010
hotkey ATKD 00000015 00000017
hotkey ATKD 00000016 00000015
hotkey ATKD 00000017 00000017
hotkey ATKD 00000018 00000017
hotkey ATKD 00000019 00000017
hotkey ATKD 0000001a 00000018
hotkey ATKD 0000001b 0000001b
hotkey ATKD 0000001c 0000001d
hotkey ATKD 0000001d 0000001e
hotkey ATKD 0000001e 0000001f
hotkey ATKD 0000001f 000001c0
[total bright again]

But the events are not translated to proper keycodes by acpi_fakekey. The scripts in /etc/acpi should trigger acpi_fakekey with these variables: 

KEY_BRIGHTNESSDOWN=224
KEY_BRIGHTNESSUP=225

, and they seem to trigger those commands, but they do not generate an x event in the end. The fact is that running acpi_fakekey 224 (or 225) as root does nothing, although other simple codes (for letters keys, for example) do produce letters. 

If I make the appropriate scripts in /etc/acpi non-executable,  I still can controll brightness via fn keys...

This Debian bug report thread suggests that there was a bug in acpi that prevented acpi_fakekey from creating certain x events. It was not conclusive that the bug was solved.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373660

could you please verify if this is a duplicate of bug #49481?

(In reply to comment #7)
> could you please verify if this is a duplicate of bug #49481?

It does not seem to be the same bug. As I described earlier, I am not even able to load the asus-laptop module. Applying the patch doesn't help me.

I noticed two lines like this in my dmesg output:

[    2.391606] ACPI Warning: _BQC returned an invalid level (20120320/video-472)

Which might be related to the backlight...

You can't load asus-laptop because it's not installed correctly.
Running:
$ sudo depmod -ae

should help. Else try to load dependencies by hand.

The ACPI warning may indicate that the ACPI backlight implementation is not really correct. Loading asus-laptop and booting with acpi_backlight=vendor may help.

(In reply to comment #9)
> You can't load asus-laptop because it's not installed correctly.
> Running:
> $ sudo depmod -ae
> 
> should help. Else try to load dependencies by hand.
> 
> The ACPI warning may indicate that the ACPI backlight implementation is not
> really correct. Loading asus-laptop and booting with acpi_backlight=vendor
> may
> help.

The module was installed with the kernel like all the other modules and should be installed correctly. Running depmod doesn't help.

Running:
$ modprobe -D asus-laptop
gives:
insmod /lib/modules/3.6.8/kernel/drivers/platform/x86/asus-laptop.ko
which shows that the module has no dependencies.

As you can see, I am now running kernel 3.6.8.

I have tried with various acpi_osi and acpi_backlight kernel arguments, but this doesn't help.

This module clearly has dependencies. If you still have 'Unknown symbols in module', then something is wrong with your kernel config, or the way you install modules. asus-laptop clearly depend on sparse-keymap for example.

(In reply to comment #11)
> This module clearly has dependencies. If you still have 'Unknown symbols in
> module', then something is wrong with your kernel config, or the way you
> install modules. asus-laptop clearly depend on sparse-keymap for example.

I guess all its dependenices are built in then. I can see that sparse-keymap is built-in:
CONFIG_INPUT_SPARSEKMAP=y

I have attached my kernel config file.

Created attachment 87701 [details]
Kernel configuration file

And you still have "unknown symbol sparse_keymap_free" ?
Can you remove all modules named asus-laptop.ko in /lib/modules/${KVER}/ (use find for that, there may be another one), and rebuild/reinstall it from your current kernel source tree (if possible using make modules_install).

I deleted the module from /lib/modules and rebuilt the kernel with modules. I then installed the modules using "make modules_install". This time I chose to build sparse-keymap and input-polldev as modules. Now, after running depmod -a, these two are listed as dependencies of asus-laptop. When I try to load asus-laptop with "sudo modprobe -v asus-laptop" I get this output:

insmod /lib/modules/3.6.8/kernel/drivers/input/sparse-keymap.ko 
insmod /lib/modules/3.6.8/kernel/drivers/input/input-polldev.ko 
insmod /lib/modules/3.6.8/kernel/drivers/platform/x86/asus-laptop.ko 
modprobe: ERROR: could not insert 'asus_laptop': No such device

So the two dependencies are loaded correctly, but asus_laptop still will not load. Also, now I get no error messages in dmesg or systemd/journalctl when trying to load the module.

Can you try asus-nb-wmi ?

(In reply to comment #16)
> Can you try asus-nb-wmi ?

How do I try this driver? 

I can see that the asus-nb-wmi.c file exists in the kernel source, but the asus-laptop driver is the only option available when configuring the kernel...

You may need to enable some depencies to build it. KConfig / xconfig should be able to help you find them.

Thanks, I was missing the PCI hotplug dependency. So, the asus-nb-wmi driver loads succesfully, but there are unfortunately no key events registered by xev or KDE when pressing the hotkeys. The following output is logged by dmesg when the driver loads:

Dec 03 19:56:44 mephisto kernel: wmi: Mapper loaded
Dec 03 19:56:44 mephisto kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Dec 03 19:56:44 mephisto kernel: asus_wmi: ASUS WMI generic driver loaded
Dec 03 19:56:44 mephisto kernel: asus_wmi: Initialization: 0x1
Dec 03 19:56:44 mephisto kernel: asus_wmi: SFUN value: 0x1a0af7
Dec 03 19:56:44 mephisto kernel: input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input6
Dec 03 19:56:44 mephisto kernel: asus_wmi: Disabling ACPI video driver

I can see that the brightness level is correctly registered in the file:
/sys/devices/platform/asus-nb-wmi/backlight/asus-nb-wmi/brightness

and by the xbacklight.

Ok, that's a first step. Is the backlight updated when you press the key ?
Can you try to boot with acpi_backlight=video and check again ?

Then, could you try with this patch: https://github.com/iksaif/platform-drivers-x86/commit/c8d90c640cc309b1b3d47f4503cf6e57e50be69d.patch ?

(In reply to comment #20)
> Ok, that's a first step. Is the backlight updated when you press the key?

Yes, the backlight is updated when I press the hotkeys, and the value in the aforementioned file is also updated.

> Can you try to boot with acpi_backlight=video and check again?

When I boot with this option instead of acpi_backlight=vendor, the /sys/devices/platform/asus-nb-wmi/backlight directory disappears. When using this option there are still no events triggered in xev/KDE.

> Then, could you try with this patch:
>
> https://github.com/iksaif/platform-drivers-x86/commit/c8d90c640cc309b1b3d47f4503cf6e57e50be69d.patch
> ?

The patch won't succeed on the asus-wmi.c file. The other three files are ok. I have attached the asus-wmi.c.rej file.

Created attachment 88401 [details]
Rejected changes when applying patch to asus-wmi.c

If the backlight is correctly updated, your are not supposed to get keys (else userspace would try to to adjust the backlight again).
You'll get an uevent, that userspace can use to display an OSD. Currently Neither KDE or Gnome are doing that.

- https://bugs.kde.org/buglist.cgi?quicksearch=uevent+backlight
- https://bugzilla.gnome.org/show_bug.cgi?id=672380

Hello, 
I also own an Asus X53S (slightly different though from the Rthomsen's one, but the DSDT is basically identical). Here my experience ad issues with the backlight. I'm on Linux kernel 3.7.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CASE A: boot without specifying acpi_backlight=vendor (thus backlight managed by video instead of asus-wmi/asus-nb-wmi)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. `ls /sys/class/backlight` gives:

/sys/class/backlight/acpi_video0
/sys/class/backlight/acpi_video1
/sys/class/backlight/intel_backlight

2. `grep . /sys/class/backlight/*/*` with backlight at maximum (cleaned up output):

/sys/class/backlight/acpi_video0/actual_brightness:10
/sys/class/backlight/acpi_video0/bl_power:0
/sys/class/backlight/acpi_video0/brightness:10
/sys/class/backlight/acpi_video0/max_brightness:10
/sys/class/backlight/acpi_video0/type:firmware

/sys/class/backlight/acpi_video1/actual_brightness:10
/sys/class/backlight/acpi_video1/bl_power:0
/sys/class/backlight/acpi_video1/brightness:10
/sys/class/backlight/acpi_video1/max_brightness:10
/sys/class/backlight/acpi_video1/type:firmware

/sys/class/backlight/intel_backlight/actual_brightness:4882
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:4882
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw

3. `grep . /sys/class/backlight/*/*` with backlight reduced by Fn-key gives an identical output, so files under /sys/class/backlight do not get updated, while Fn-keys work correctly. The gnome-control-center brightness slider does not get updated.

4. `echo <new_brightness> > /sys/class/backlight/[acpi_video[0|1] | intel_backlight]/brightness` actually changes the LCD brightness and updates (only) the corresponding actual_brightness file (not all three). The gnome-control-center brightness slider does not get updated.

5. Adjusting brightness through the gnome-control-center brightness slider works, but only the files /sys/class/backlight/acpi_video1 get updated.

6. `dmesg |grep -i acpi` shows two warnings (among other things):

ACPI Warning: _BQC returned an invalid level (20120913/video-486)

(one for acpi_video device, I guess).

7. Pressing Fn-keys with `acpi_listen` running gives only a sequence of:

PNP0C14:01 000000ff 00000000

(I guess because everything is managed via WMI, so this is only a notification for the WMI event).

8. Pressing Fn-keys with `udevamd monitor` running gives nothing.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CASE B: boot specifying acpi_backlight=vendor (thus backlight is managed by asus-wmi/asus-nb-wmi)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. `ls /sys/class/backlight` gives:

/sys/class/backlight/asus-nb-wmi
/sys/class/backlight/intel_backlight

2. `grep . /sys/class/backlight/*/*` with backlight at maximum (cleaned up output):

/sys/class/backlight/asus-nb-wmi/actual_brightness:10
/sys/class/backlight/asus-nb-wmi/bl_power:0
/sys/class/backlight/asus-nb-wmi/brightness:10
/sys/class/backlight/asus-nb-wmi/max_brightness:10
/sys/class/backlight/asus-nb-wmi/type:platform

/sys/class/backlight/intel_backlight/actual_brightness:4882
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:4882
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw

3. `grep . /sys/class/backlight/*/*` with backlight reduced by Fn-key gives:

/sys/class/backlight/asus-nb-wmi/actual_brightness:7
/sys/class/backlight/asus-nb-wmi/bl_power:0
/sys/class/backlight/asus-nb-wmi/brightness:7
/sys/class/backlight/asus-nb-wmi/max_brightness:10
/sys/class/backlight/asus-nb-wmi/type:platform

/sys/class/backlight/intel_backlight/actual_brightness:4882
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:4882
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw

So asus-wmi actually seems to manage correctly the ACPI brightness stuff. The gnome-control-center brightness slider does not get updated.

4. `echo <new_brightness> > /sys/class/backlight/[asus-nb-wmi | intel_backlight]/brightness` actually changes the LCD brightness and updates (only) the corresponding actual_brightness file (not all three). The gnome-control-center brightness slider does not get updated.

5. Adjusting brightness through the gnome-control-center brightness slider works, but only the files under /sys/class/backlight/intel_backlight get updated.

6. In `dmesg |grep -i acpi` the _BCQ warnings are gone.

7. Pressing Fn-keys with `acpi_listen` running still gives only a sequence of:

PNP0C14:01 000000ff 00000000

8. Pressing Fn-keys with `udevamd monitor` running gives a sequence of:

KERNEL[1084.782718] change   /devices/platform/asus-nb-wmi/backlight/asus-nb-wmi (backlight)
UDEV  [1084.783201] change   /devices/platform/asus-nb-wmi/backlight/asus-nb-wmi (backlight)

Which AFAIK is the correct notification behavior (and is a missing feature of Gnome not intercepting and managing them).


~~~~~~~~~~~
Conclusions
~~~~~~~~~~~
On this machine I think one should go with acpi_backlight=vendor and wait for a correct backlight uevent support by desktop environments.

Still it is unclear to me which is the interaction path between desktop power management and the files under /sys/class/backlight (i.e. see points A5 and B5). I would be glad if anyone can explain that.

And still I could not understand why the generic ACPI drivers are preferred by default over the specific ones, which are supposed to better handle the devices. Could anyone explain that too?

Sorry for the lenghty post, but I tried to be exhaustive. Thanks!

(In reply to comment #24)
> ~~~~~~~~~~~
> Conclusions
> ~~~~~~~~~~~
> On this machine I think one should go with acpi_backlight=vendor and wait for
> a
> correct backlight uevent support by desktop environments.

Right.

> 
> Still it is unclear to me which is the interaction path between desktop power
> management and the files under /sys/class/backlight (i.e. see points A5 and
> B5). I would be glad if anyone can explain that.

Documentation/ABI/stable/sysfs-class-backlight has some info on these files.

Usually, when hotkey is pressed to adjust backlight, there are three cases:
1 A keycode is generate to user space. In this case, we need to remap the keycode to standard backlight brightness up/down code, so that user space can react accordingly(the remap can either be done by driver or by udev);
2 Firmware sends driver a notification, and driver will send a key event(e.g. standard brightness up/down key code) corresponding to this notification to user space, so user space can again react accordingly;
3 Firmware directly manipulates the backlight and then sends driver a notification and driver will send user space an uevent to let them know something has already happened.

For the first 2 cases, user space will adjust the backlight level through one of the available backlight interfaces in /sys/class/backlight.

And after any of the operations of the above 3 cases, the file's content may have changed.

> 
> And still I could not understand why the generic ACPI drivers are preferred
> by
> default over the specific ones, which are supposed to better handle the
> devices. Could anyone explain that too?

GNOME did this, I don't know why.
The gnome-settings-daemon code showed that, g-s-d will prefer backlight interface of the following order: firmware(acpi_video) > platform(asus/acer/etc._wmi) > raw (intel/radeon/etc._backlight)

> 
> Sorry for the lenghty post, but I tried to be exhaustive. Thanks!

It's very clear, thanks.

This patch may worth a try:
https://bugzilla.kernel.org/attachment.cgi?id=98031