acpi4asus

hey guys could you tell me how to install this patch then i can tell you whether it works with ul30vt or not.

Hey is this problem solved?

No it's not, I'll try to look into it this weekend.

Looking at the patch, I don't remember why exactly this patch is needed. Could someone with this laptop refresh this patch and resend it ?
Thanks

Anonymous wrote:

Here's a patch that applies cleanly on 3.2.0RC3. Couldn't test it however, as I cannot find an easy way to do an out-of-tree build for this kernel module (now that it requires sparsekmap). If you could provide me with the proper way of building (without doing the entire kernel) please let me know so I can test it for you!

use that:

git clone git://git.iksaif.net/acpi4asus-dkms.git

There is a Makefile at the top that let build the modules out of tree. This should work as long as your installed kernel support all the dependencies. If it doesn't, please tell me the kernel version you're using.

Anonymous wrote:

Well now, I promised a patch that applies cleanly... This one doesn't introduce whitespace errors :)

As for testing. I cloned that repo and hit the big bad make-button. Making however isn't the problem. Insmod gives me the following:
[ 871.981846] asus_laptop: Unknown symbol sparse_keymap_free (err 0)
[ 871.981975] asus_laptop: Unknown symbol input_allocate_polled_device (err 0)
[ 871.982053] asus_laptop: Unknown symbol input_free_polled_device (err 0)
[ 871.982153] asus_laptop: Unknown symbol sparse_keymap_report_event (err 0)
[ 871.982196] asus_laptop: Unknown symbol sparse_keymap_setup (err 0)
[ 871.982287] asus_laptop: Unknown symbol input_register_polled_device (err 0)
[ 871.982344] asus_laptop: Unknown symbol input_unregister_polled_device (err 0)
.. that's on 3.1.2-1.fc16.x86_64.

modprobe sparse-keymap
modprobe input-polldev

:)

Right, Thanks!

Disregard all patches though, apparently a lot has changed since I last wrote that beast. Here's the status of this bug though:
- acpi_listen picks up the keypress.
- xev does not.
- The proposed patch was silly. There already is special brightness code in place that covers the 0x10-0x2f range.
- Brightness does not get handled by asus-laptop by default but rather (I'm guessing) by video. Booting with acpi_brightness=vendor makes asus-laptop handle brightness. In both these cases I can adjust the brightness through the system interfaces. Keypresses however do not manipulate the brightness.
- Enabling "hybrid graphics" in the BIOS setup utility makes the brightness keys magically work. We're clearly talking about a BIOS bug here.

The problem seems simple. Brightness ACPI keypress events don't reach the actual brightness handler. My initial thought therefore was associating the 0x10 and 0x20 with brightnessup and brightnessdown. Then detect the UL50V and if so, pass on the keypress to sparse-keymap. To reach this goal I altered asus_acpi_notify to (in the case of a brightness event) make sure asus_input_notify is called with event&0x30 if asus->backlight_device is NULL (and an UL50V was detected). I was hoping the big bad brightness mechanics in kernel would then take over and translate this keypress to a brightness change. Unfortunately, all that happened was Gnome showing the brightness bar increase by one step and one step only (without the accompanying brightness change). No module actually stood up and handled this keypress.
Having seen this behaviour I would have expected booting with acpi_brightness=vendor would solve the problem. Then asus-laptop is supposed to own the backlight device. It actually does, given /sys/class/backlight/asus-laptop now exists. Still no response to keypresses though.
Now, being not so gifted when it comes to ACPI development, I am unaware of any mechanics that exist with the goal of passing on this keypress to another ACPI device with the purpose of forcing an update in the brightness level. Updating the BIOS is unacceptable at the moment too, given the option to disable hybrid graphics disappeared from the setup utility. A module that supports this graphics card switching is far from finished at the moment. What's the right course of action now?

Anonymous wrote:

Right, Thanks!

Disregard all patches though, apparently a lot has changed since I last wrote that beast. Here's the status of this bug though:
- acpi_listen picks up the keypress.
- xev does not.

Yep, on all other model the brightness is handled in hardware, so the key must not be reported.

- Brightness does not get handled by asus-laptop by default but rather (I'm guessing) by video. Booting with acpi_brightness=vendor makes asus-laptop handle brightness. In both these cases I can adjust the brightness through the system interfaces. Keypresses however do not manipulate the brightness.

Yep, default is generic acpi/video.ko module. And yep, with the current code keypress as not relayed to userspace as input events (but are as ACPI events).

- Enabling "hybrid graphics" in the BIOS setup utility makes the brightness keys magically work. We're clearly talking about a BIOS bug here.

What's the original feature controlled by this option ? Something like multi-graphic-card support ?

The problem seems simple. Brightness ACPI keypress events don't reach the actual brightness handler. My initial thought therefore was associating the 0x10 and 0x20 with brightnessup and brightnessdown. Then detect the UL50V and if so, pass on the keypress to sparse-keymap. To reach this goal I altered asus_acpi_notify to (in the case of a brightness event) make sure asus_input_notify is called with event&0x30 if asus->backlight_device is NULL (and an UL50V was detected). I was hoping the big bad brightness mechanics in kernel would then take over and translate this keypress to a brightness change.

The kernel doesn't handle keypress, the desktop environment does. Most of them do that correctly.

Unfortunately, all that happened was Gnome showing the brightness bar increase by one step and one step only (without the accompanying brightness change). No module actually stood up and handled this keypress.
Having seen this behaviour I would have expected booting with acpi_brightness=vendor would solve the problem. Then asus-laptop is supposed to own the backlight device. It actually does, given /sys/class/backlight/asus-laptop now exists. Still no response to keypresses though.

If /sys/class/backlight/ works (either video or asus-laptop), and the DE catch a keyboard up/down key, it's its responsability to handle it. I know that recent KDE and gnome can handle that correctly.

Now, being not so gifted when it comes to ACPI development, I am unaware of any mechanics that exist with the goal of passing on this keypress to another ACPI device with the purpose of forcing an update in the brightness level. Updating the BIOS is unacceptable at the moment too, given the option to disable hybrid graphics disappeared from the setup utility. A module that supports this graphics card switching is far from finished at the moment. What's the right course of action now?

Enable the hack that makes asus-laptop send KEY_BRIGHTNESSDOWN and KEY_BRIGHTNESSUP when the keys are pressed. Check that it works correctly with:
- showkey in a real tty
- xev under X

And then we will have to find out why gnome can't control the brightness when it receive the events.

Hello,
thank you for all your work on this the current state as far as I am concerned is that in gnome and kde the brightness works however in neither lxde nor xfce it does.

That's is because lxde and xfce probably don't handle (correctly?) brightness keys. You should contact xfce and/or lxde developpers for that.