brightness buttons on new HP 6930p laptop

Let me try to rephrase the audio problem.

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.

Updated the laptop to 8.10RC and got the hardware mute switch repaired. The original problem description is updated accordingly, and the "rephrase" posted above can be ignored.

I don't seem to be the only one who has no sound on the speakers:
http://www.linlap.com/wiki/HP+EliteBook+6930P

I have a HP 6735b notebook model and can confirm the problems above.

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.)

Specifically, he added:

        <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains="6930p">
          <!-- HP Elitebook 6930p -->
          <append key="input.keymap.data" type="strlist">e012:brightnessdown</append> <!-- FnF7 (brightness down) -->
          <append key="input.keymap.data" type="strlist">e017:brightnessup</append> <!-- FnF8 (brightness up) -->
        </match>

inside the existing <match> block for system.hardware.vendor prefix Hewlett-Packard.

This gave me working brightness keys.

Thanks Matt.

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?

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">
  <device>

    <match key="@input.originating_device:info.linux.driver" string="atkbd">
      <match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" prefix="Hewlett-Packard">
        <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains="6930p">
          <!-- HP Compaq 6930p -->
          <append key="input.keymap.data" type="strlist">e012:brightnessdown</append> <!-- FnF9 (brightness down) -->
          <append key="input.keymap.data" type="strlist">e017:brightnessup</append> <!-- FnF10 (brightness up) -->
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

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.

Not sure why it say 7.15 here and 8.17 in uname. The latter is correct. It's a custom kernel, the only change is enabling 64G. Running the default kernel makes no difference.

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. :-)

Today's update which included new versions of the gnome-power-manager (2.24.0-0ubuntu8.1) and libx11-6 (2:1.1.5-2ubuntu1.1) improved the situation on my laptop model a bit.

The Fn+F8 (battery hint) is now working.

The dimming of the brightness after disconnecting power is now happening, although very very slowly, provided I set xrandr to native, but I have the same problem as reported by Michael Hackett.

The maximum brightness that is available still depends on whether A/C was connected at boot time or not.

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:

fn-escape (sysinfo): Xorg rejects with (WW) AT Translated Set 2 keyboard: unable to handle keycode 465
fn-f3 (sleep): keycode 142; works
fn-f4 (video-switch): keycode 227; works, but ATI driver ignores xrandr run by gnome-power-manager
fn-f6 (unmarked!): keycode 152
fn-f8 (battery popup): keycode 236; works
fn-f9/f10 (brightness down/up): keycodes 224/225; both work
fn-f10 (toggle light sensor): keycode 191; toggle is in hardware

Info (also an ACPI direct-launch button): keycode 358; nothing in Xorg
Radio: electrically unplugs bluetooth adapter, and applies rfkill to Intel 5300 card (NetworkManager misses this)
Presentation: keycode 193; works
Mute: no keycode
Volume down/up: keycodes 114/155; both work

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.

I will be out of the office December 24, 2008 to January 5, 2009. If you need immediate assistance please contact John Elton by phone 215-996-9000 or by email <email address hidden>. Thank you.

Some new discovery: it looks like the hal FDI file mentioned here: https://bugs.launchpad.net/ubuntu/+source/hal-info/+bug/325560 needs to be updated to add the EliteBook models in two places: one for backlight control and one where the current fdi file matches for "Compaq". Even after that, I still get unreasonably high keycodes for fn_esc, info, and presentation, as mentioned here for a completely different laptop: https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/267495.

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.

ANother new thing I noticed: after installing (and fixing) HDAAnalyzer, as shown here, I was able to confirm that asserting GPIO 0 on the adi1984 chip sets the hardware mute feature.
http://article.gmane.org/gmane.linux.alsa.devel/59132

Relevant lines from Windows .inf file:

HKR,GlobalSettings,GPIO_1, 0x00010001, 0x00000008 ; First bit = 8 for inverted and 0 for normal polarity
HKR,GlobalSettings,GPIO_2, 0x00010001, 0x0000000A ; Enable HW Mute control

;GPIO_1 Mute LED commands
HKR,InitVerbs,0019, 0x00010001, 0x00171606 ; Disable 1984A GPIO bit 0
HKR,InitVerbs,0020, 0x00010001, 0x00171702 ; Bit set for an Output

Correction: I meant GPIO 1.

hmm, it looks like the FDI file has been fixed in hal-info git.
http://cgit.freedesktop.org/hal-info/tree/fdi/information/10freedesktop/30-keymap-hp.fdi

The "unable to handle keycode" bug seems like this one -- just finally marked as being worked on... today:
http://bugs.freedesktop.org/show_bug.cgi?id=11227

That still leaves the mute LED issue behind, though.

Now I've figured out a bit more about the GPIO usage:
GPIO 0 (input) acts as headphone detection -- 0 if present, 1 if absent.
GPIO 1 (output) controls muting and LED -- active high ('1' mutes).
GPIO 2 (input) returns LED status (pressing hardware button toggles it) -- active high.

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).

Hmm, looks like some progress is being made on the Mute-LED front.
http://groups.google.com/group/linux.kernel/msg/d71c68275456957a

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.

Hi Guys,

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:

https://wiki.ubuntu.com/KernelTeam/MainlineBuilds

Also the most recent 9.10 Karmic Alpha release is available for testing at http://cdimage.ubuntu.com/releases/karmic/ . Thanks.

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.

Tried all this stuff on latest Ubuntu 10.10 and Elitebook 6930p. Most of these problems went away already. Here is what still doesn't work for me very well:

1. Hardware mute button actually mutes/unmutes internal speakers though sound mixer applet is not updated properly. Though when muting/unmuting sound with GUI, hardware mute button indicator properly reflects the changes.

2. Hardware mute button doesn't do anything for external speakers. Though when muting/unmuting sound with GUI, sound from external speakers properly reflects the changes.

I think we can rephrase the bug dropping mention about brightness since everything related to this functionality works like a charm.

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.

Please let us know your results. Thanks in advance.

I have a 6930p and see none of the issues mentioned (although I do have lots of others!). Plus this bug is for an end of life release so it should be closed.