Bug Description

I purchased a brand new laptop model: HP 6930p with Intel 4500MHD graphics and Intel 82801I (ICH9) HD Audio, and I installed Intrepid with the latest updates. I have the following problems:

- The buttons for controlling the brightness (Fn F9/F10) don't work. xev does not show any events for these buttons. Trying to write values into /proc/acpi/video/GFX0/DD0?/brightness has no effect.
- Upon connect/disconnect the AC power, there is a little pop-up on the screen indicating that the brightness goes up or down, but there is no change in brightness.
- If booted with AC connected, the brightness is high; if booted on battery, brightness is low. This won't change until reboot.

The machine has three physical controls: volume up, volume down and mute. It also has an LED indicating the mute status. Gnome and Vista have a master volume slider and a mutton button on their GUIs. Normally, any action on a physical control is reflected by the GUI control and vice versa.

This machine seems to have a broken physical mute button, but that shouldn't be a concern. It should still be possible to mute/un-mute by clicking a mute button on the GUI. This works in Vista, but not in Ubuntu.

Sound on the front speaker seems to depend on the status of the mute LED. Since in Ubuntu this is always on, I hear nothing. Sound on the headset is fine and can be controlled normally.

The bug about the headphone vs internal speakers is also filed as https://bugs.launchpad.net/bugs/269027. Apparently the snd_hda_intel driver doesn't properly detect the model configuration but knows what to do if you load it with model=mobile.

On my 6930p, the hardware mute switch+LED does work, but at a level that's apparently invisible to (or at least divorced from) Linux's software mixer. It never mutes the headphones, and does mute the internal speakers, and turns itself on at various times when I never told it to.

Also, for the brightness keys: a friend who's better versed than I in the ways of hal showed me how to copy some entries from /usr/share/hal/fdi/information/10freedesktop/30-keymap-hp.fdi to /usr/share/hal/fdi/information/20thirdparty/30-keymap-private.fdi. (It probably would have sufficed to edit 30-keymap-hp.fdi in place, too.)

Sound works now for me as well. The hardware mute button and the software mute button work independently, i.e. if you press one, the status change isn't reflected in the other one. Furthermore, the software mute has precedence over the hardware mute. Not perfect, but much better than no sound.

I did not have a .../20thirdparty/30-keymap-private.fdi on my machine. Now I have one with the contents included below. Result: when I press Fn/F9 or Fn/F10 I now get the brightness icon on the screen that indicates how the brightness goes up or down. This wasn't there before, but the brightness still doesn't change.

By the way, does you 6930p come with Intel video, or do you have an ATI card?

The brightness problem persists. There are at least three events that should change the brightness of this machine's screen:
- Function keys Fn/F9 and Fn/F10
- Gnome Brightness Applet
- Connect/Disconnect A/C Power

All three have the same results:
- A pop up on the screen indicating brightness going up and down.
- The current value in /proc/acpi/video/GFX0/DD04/brightness changes.
- The brightness of the screen does no change, it remains at 100% if power was connected during boot or at 44% if the machine booted on battery.

The laptop also has an ambient light sensor that can be enabled or disabled by pressing Fn F11. This works as intended, and the brightness of the screen changes with the ambient light. However, this has no effect on the current value in /proc/acpi/video/GFX0/DD04/brightness. The BIOS allows me to enable or disable the ambient light sensor, but this also has no impact on the problem.

The value in /sys/devices/virtual/backlight/acpi_video0/brightness also changes whenever one of the three events mentioned above happens.

Today I found the following: When I set
xrandr --output LVDS --set BACKLIGHT_CONTROL native
then I can control the brightness using the function keys, xbacklight and xrandr. The gnome applet also works, but is too slow to be useful. In this mode the values in /sys and /proc/acpi don't change anymore. Dis/Connecting the A/C power has no impact in this mode.

However, there is still a dependency on the power status during boot. It seems that the maximum brightness available is still set at that time. I have not found a way to increase the brightness beyond that level except plug-in & reboot.

xrandr --output LVDS --set BACKLIGHT_CONTROL kernel
switches everything back to as it was before.

My variant of the 6930 has ATI graphcs (Radeon HD3400 series). My screen brightness experience is somewhat better than you describe. The Fn-controlled keys on the keyboard work for brighter/dimmer; the gnome applet also works; the brightness state agrees between these two methods. xbacklight says "no outputs have backlight property".

However, ambient brightness detection doesn't seem to work. Nothing happens when I press Fn-F11 which is supposed to go to auto mode. If I'm on battery, sometimes the screen will dim itself to 44% and I have to go manually readjust it to the desired level, and it won't stay there for long; it'll keep jumping back to 44%. If I'm plugged into AC, then the brightness stays where I put it.

Also the "dim display when idle" checkbox in the gnome power preferences is somewhat funny, but I suspect this isn't hardware-specific. Its definition of "idle" sees mouse but not keyboard input, and always kicks in after 1 minute, regardless of what delay I specify in the screensaver preferences. So if I have "dim display when idle" selected, the screen will often dim when I'm not idle (I frequently go more than a minute without touching the mouse!). So, I've deselected the dim-on-idle option.

I've got an HP 2230s and I had the same sound and LCD brightness issues, and the above instructions fixed the sound and got the brightness controls working, at least temporarily. Now, however, the screen starts to dim itself slowly over a few minutes time and I have to flip the xandr BACKLIGHT_CONTROL setting back to kernel and native again to get control back. Really difficult to get much work done. :-)

I have an EliteBook 8530w (with ATI card, not nvidia), and have many of the same issues: mute control and hotkeys don't work very well, as stated; the only difference is that my backlight control seems to work fine. Although the brightness hotkeys work in gnome after I run setkeycodes, the brightness panel-applet will give "cannot get brightness" for some values of brightness... but not for others.

_After_ using setkeycodes on various keys shown in dmesg, only some hotkeys work, as follows:

Note that I am using the Jaunty kernel, however. The Jaunty kernel adds correct sound card detection, but does not affect these keycodes.
The Jaunty kernel's new hp-wmi driver provides a sysfs interface to the two separate bluetooth and wifi rfkill functions, and the ambient light sensor status -- and the lis3lv02d driver provides a joystick interface to the accelerometer.

No matter what I do, the mute key gives me nothing at all. Oddly enough, the mute key actually does send the mute keycode if snd-hda-intel has not yet loaded during this boot, but once the audio driver loads, it stops sending any events. In addition, the LED state does not reflect the ALSA master mute state.

It seems ALSA needs to watch GPIO 2, and when it detects a change, it must update the software mixer status, update GPIO 1 value, and send a "display the volume without changing it" event of some sort (as is done with the Thinkpad hardware volume control).

As I discovered when testing the 2.6.31-rc2-based kernel, this fix applies only to the 'mobile' model (which lacks the second capture stream and the dock inputs), and not to my 'laptop' model. In addition, it only functions in one direction: the software mixer will update the hardware LED, but the button does not update the software.

If there is some official upstream bug report for this, would somebody please link it? I can't find where the "official" decision to add that feature came from.

If there doesn't already exist an upstream bug report, it might not hurt to open one at bugzilla.kernel.org if you still experience this issue with the most recent mainline kernel. There are mainline kernel builds that you should be able to test with at the following:

I have not been able to resolve the mute issue on a 6730b, but I did find a nice workaround, which is setting a keyboard shortcut to control mute for my laptop. In my case, I set Ctrl+~ as mute, and it works fine. So, that's a bridge between the hardware and software mute, but the context touch-button still only changes the volume state to mute (in the panel) with no effect on actual sound volume. Volume slider touch-buttons work fine.

Dirk, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.