ASUS WMI driver does not emit brightness key events

Bug #959106 reported by AceLan Kao
38
This bug affects 5 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Invalid
Medium
linux (Ubuntu)
Fix Released
Medium
Canonical Kernel Team
Nominated for Oneiric by Anthony Wong
Nominated for Precise by Anthony Wong

Bug Description

For all ASUS machines, it will only notify the userspace app by udev event
while the brightness value is changed, instead of keyevent.

The procedure in the asus-wmi kernel module is as described below
1. receive the keyevent from WMI
2. if the brightness event is not handled by ACPI, then update the brightness
value through WMI
3. call backlight_force_update(), it will
  1. send a change notification on the actual_brightness file (userspace can
monitor it using inotify or related), and
  2. send a uevent which can be catched by udev or others (with SOURCE
being an env variable containing the source of this change)

The problem is that it won't report keyevent, so g-s-d won't show the
brightness OSD. But it actually reports the event, uevent.

It won't harm to monitor the uevent and read the brightness value from
actual_brightness and shows the OSD, even if there is already a keyevent
reported.
Please consider to add this feature, thanks.

The brightness uevent looks like this
==
KERNEL[16407.000334] change
/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
KERNEL[16407.000555] change
/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
UDEV [16407.000605] change
/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
KERNEL[16407.000730] change
/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
UDEV [16407.000997] change
/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
UDEV [16407.001164] change
/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
KERNEL[16407.002040] change
/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
UDEV [16407.002212] change
/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 (backlight)
==

Revision history for this message
AceLan Kao (acelankao) wrote :
tags: added: blocks-hwcert-enablement
Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

Since this is blocking cert of this machine for precise, culd the desktop team please take a look and see if it is addressible?

Changed in gnome-settings-daemon (Ubuntu):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Revision history for this message
Martin Pitt (pitti) wrote :

This would be a bad hack to workaround a kernel bug. IMHO the asus WMI driver should be fixed to actually emit proper key events, then user space will handle this just fine. Please let's fix this at the proper place.

affects: gnome-settings-daemon (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → Canonical Kernel Team (canonical-kernel-team)
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 959106

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Martin Pitt (pitti)
summary: - brightness changing problem in ASUS machines
+ ASUS WMI driver does not emit brightness key events
Revision history for this message
Seth Forshee (sforshee) wrote :

So the bug is that the brightness changes but the notifier isn't displayed?

If the driver sends the key event, then isn't g-s-d going to change the brightness again? I think this is why the driver behaves this way. It's providing information to userspace to indicate that the brightness has changed, whereas the key events tell userspace to actually change the brightness.

Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
AceLan Kao (acelankao) wrote :

Seth,

No, asus-wmi driver doesn't send out the key event, since it changed the brightness already.
If the driver send out the key event, g-s-d will changes the brightness again, it's not we want.
So, it only send out the uevent to notify the g-s-d that brightness is changed, please read the actual_brightness and update it on the OSD.

Many wmi driver send out this kind of uevent, but no userspace app listen to this event.
The key event and uevent is not equal and they actually sending out the different meaning.
So, I don't think it's a bug in kernel, and it should rely on userspace app, such as gnome-settings-daemon, to cover this part.

Keng-Yu Lin (lexical)
affects: linux → gnome-settings-daemon
Revision history for this message
Seth Forshee (sforshee) wrote :

Subscribing Martin to ensure he sees the comments being made here.

Martin, can you respond to the comments made here and on the upstream bug? Among the kernel devs there seems to be a consensus that the kernel *should not* be sending key events in situations like this.

Revision history for this message
Martin Pitt (pitti) wrote :

I agree, if the brightness keys are hardwired, then it sounds better to just let the notification popups not work than doing brightness changes twice.

Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: Unknown → Incomplete
Revision history for this message
Shih-Yuan Lee (fourdollars) wrote :

There is a patch provided by Gary Ching-Pang Lin. https://bugzilla.gnome.org/show_bug.cgi?id=672380#c7
I made Debian packages for amd64 on http://people.canonical.com/~sylee/959106/.
Does anyone want to try this package to see how it works?

Revision history for this message
Alex Wolfson (awolfson) wrote :

There is another bug which seems to be very similar

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/257827

Revision history for this message
Stéphane Gourichon (stephane-gourichon-lpad) wrote :

Hi, I'm wondering if the bug I'm experiencing (bug 1042359 ) is linked to this one.

What are the effects, observable by the user, of the bug being discussed here ?

Revision history for this message
AceLan Kao (acelankao) wrote :

gouri, yes, that's the exactly the same problem you encountered.
Sorry, we don't have any progress for this issue.

Changed in gnome-settings-daemon:
status: Incomplete → New
Changed in gnome-settings-daemon:
status: New → Unknown
Changed in gnome-settings-daemon:
status: Unknown → New
Revision history for this message
AceLan Kao (acelankao) wrote :

No good result while discussing with gnome-settings-daemon maintainer, so asus-wmi driver will report the key events anyway.
This will lead to another problem that the brightness will be adjusted twice by a single key stroke.
This patch is still in platform-x86 maintainer's tree, and will be merged into 3.8 kernel soon.

commit 9049ce3da93e8c891162dd0fc3ac35d6bb66a4a3
Author: Corentin Chary <email address hidden>
Date: Thu Nov 29 09:12:38 2012 +0100

    asus-wmi: always report brightness key events

    Signed-off-by: Corentin Chary <email address hidden>
    Signed-off-by: Matthew Garrett <email address hidden>

Revision history for this message
AceLan Kao (acelankao) wrote :

This patch is in 3.9-rc1, so it won't be available for ubuntu precise/quantal/raring kernel

Changed in linux (Ubuntu):
status: Incomplete → Fix Committed
Changed in linux (Ubuntu):
status: Fix Committed → Fix Released
Changed in gnome-settings-daemon:
status: New → Confirmed
Changed in gnome-settings-daemon:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.