lcd brightness down doesn't work when gpm running (t60)

[David MacKinnon]

Binary package hint: gnome-power-manager

This is on a Thinkpad T60p

  smbios.bios.release_date = '03/15/2007' (string)
  smbios.bios.vendor = 'LENOVO' (string)
  smbios.bios.version = '79ETD1WW (2.11 )' (string)
  smbios.chassis.manufacturer = 'LENOVO' (string)
  smbios.chassis.type = 'Notebook' (string)
  smbios.system.manufacturer = 'LENOVO' (string)
  smbios.system.product = '200887G' (string)
  smbios.system.serial = 'L3HZ322' (string)
  smbios.system.uuid = 'B5858081-48EF-11CB-87E6-CC0B0B8CB930' (string)
  smbios.system.version = 'ThinkPad T60p' (string)

With gnome-power-manager running, brightness down does not function (it looks like it goes down one level then back up again).

Brightness up sometimes works, sometimes shows similar behaviour, sometimes will go up rapidly when fn-home is pressed.

The keys function as normal/expected if gpm is not running.

This sounds quite similar (not not exactly the same as) bug #81407

This is on the gutsy Tribe2 release gnome-power-manager 2.19.3-0ubuntu2

[Milosz Tanski (mtanski)]

I can confirm that on a z61t. Brightness is pretty messed up in gutsy. Sometimes it dosen't let me adjust it (when i change it, it goes right back). Other times when it does let me the little pop up for brightness never goes away (just sits in the middle of the screen).

[Erik Meitner (e.meitner)]

I also have this on a Thinkpad T60/87445 bu ( https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadT60-5BU ) running an up-to-date Gutsy as of 17 July. Using GPM 2.19.5-0ubuntu1.

On AC:
If I try to decrease the brightness(fn-End) it does not let me go any more than one step below max.(it goes up but then immediately goes back down)
dbus-monitor shows:
signal sender=:1.10 -> dest=(null destination) path=/org/freedesktop/PowerManagement/Backlight; interface=org.freedesktop.PowerManagement.Backlight; member=BrightnessChanged
   uint32 90
signal sender=:1.10 -> dest=(null destination) path=/org/freedesktop/PowerManagement/Backlight; interface=org.freedesktop.PowerManagement.Backlight; member=BrightnessChanged
   uint32 95

If I try to increase the brightness(fn-Home) it does go to max but the notification box remains on the screen and the CPU experiences about 10% usage due to Xorg, and notification-daemon. dbus-monitor at this point continuously displays:

signal sender=:1.10 -> dest=(null destination) path=/org/freedesktop/PowerManagement/Backlight; interface=org.freedesktop.PowerManagement.Backlight; member=BrightnessChanged
   uint32 100

 This will continue until I set the brightness to one step below max..

On battery:
When the AC is removed the screen dims.(Ihave it set to cut brightness 75%). If I try to increase the brightness it does not allow it.(it goes up but then immediately goes back down)
Now if I set the preferences to dim by only 20% it does not allow me to dim.(same behavior). I can increase it though. The behavior changes depending on the "Dim Display nrightness setting", especially around the 55-70% range.
If "Dim Display nrightness setting" is set to where the display will then be set at 100% brighness it gets "stuck" like above.

[Erik Meitner (e.meitner)]

Note when the "Brightness increase" seems stuck, xev reports: a continuous flow of these events:

KeyPress event, serial 30, synthetic NO, window 0x4400001,
    root 0x3d, subw 0x0, time 3653088682, (374,48), root:(1372,497),
    state 0x10, keycode 212 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x4400001,
    root 0x3d, subw 0x0, time 3653088682, (374,48), root:(1372,497),
    state 0x10, keycode 212 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Must be some kind of race condition due to something synthesizing key events?

Seems to be the same issue as bug# 81407. That bug was supposed to be resolved in Feisty.

In case this is needed:
lshal| grep smbios
  smbios.bios.release_date = '04/30/2007' (string)
  smbios.bios.vendor = 'LENOVO' (string)
  smbios.bios.version = '7IET27WW (1.08 )' (string)
  smbios.chassis.manufacturer = 'LENOVO' (string)
  smbios.chassis.type = 'Notebook' (string)
  smbios.system.manufacturer = 'LENOVO' (string)
  smbios.system.product = '87445BU' (string)
  smbios.system.serial = 'L3CB780' (string)
  smbios.system.uuid = 'C9040C01-492E-11CB-9722-D2D54B6711EE' (string)
  smbios.system.version = 'ThinkPad T60' (string)

[Marius Gedminas (mgedmin)]

This bug is also present on a Lenovo T61 running gutsy:

$ lshal|grep smbios
  smbios.bios.release_date = '04/17/2007' (string)
  smbios.bios.vendor = 'LENOVO' (string)
  smbios.bios.version = '7LET37WW (1.07 )' (string)
  smbios.chassis.manufacturer = 'LENOVO' (string)
  smbios.chassis.type = 'Notebook' (string)
  smbios.system.manufacturer = 'LENOVO' (string)
  smbios.system.product = '646655G' (string)
  smbios.system.serial = 'L3A1473' (string)
  smbios.system.uuid = '07003081-492D-11CB-81BF-CA9AB310083F' (string)
  smbios.system.version = 'ThinkPad T61' (string)

By the way, my /usr/share/hal/fdi/policy/10osvendor/10-laptop-panel-mgmt-policy.fdi has no entries for Thinkpads. I added

  <device>
    <match key="info.category" string="laptop_panel">
      <match key="/org/freedesktop/Hal/devices/computer:smbios.system.manufacturer" string="LENOVO">
        <match key="/org/freedesktop/Hal/devices/computer:smbios.system.version" contains="T61">
          <merge key="laptop_panel.brightness_in_hardware" type="bool">true</merge>
        </match>
      </match>
    </match>
  </device>

and restarted hal, but this did not fix the problem.

[cornbread (corn13read)]

This bug affects my Lenovo x60 Tablet.

Brightness does not work as to the scale either. I will press brightness down and the bar will continue to show full status when not fully bright on screen, pressing more will make bar go down but not to screens brightness scale...

[Eddie Hung (eddieh)]

I can confirm this also with a IBM X41, on the latest gutsy x86.

For me, this is a regression from Feisty and, I think, early Gutsy.

What happens for me though, is that pressing Fn+Home takes my screen very quickly through all the levels to full brightness, and Fn+End to minimum (however, pressing the opposite key stops it at that point). Also, the strange thing is that gpm cannot seem to set the requested brightness correctly - for example on battery I've set it to 50%, but once gpm detects this, it looks as if it tries to set it to 50%, but it ends up going all the way down to 0%. (In a related note, the X server seems to be responding to the AC event much slower than in Feisty, as shown by xev again)

I'm currently loading thinkpad-acpi manually using /etc/modules to enable brightness support, and I can confirm that xev receives multiple brightness up/brightness down events - and running gpm in debug mode, no daemon, shows that it is reacting to these events.

Should this be a bug filed in X server and not here in GPM, then?

[Eddie Hung (eddieh)]

I take back my last question: it does seem to be a problem with gpm not acknowledging to the X server that it has handled the events.

xev shows that only two events (one key down, one key up) are seen when gpm is not running, whereas it shows multiple events when gpm is running.

I have taken logs of xev - with and without gpm, and gpm (--no-daemon --verbose) - during a Fn+Down event and a AC unplugging event.

For reference, in the xev logs keycode 101 is brightness down, 212 is brightness up.

[Eddie Hung (eddieh)]

I can confirm that the regression for me happens between 2.19.5-0ubuntu1 (2007-07-06) and 2.19.6-0ubuntu1 (2007-08-02) - where the latest version is 2.19.6-0ubuntu2.

[TonyS (tony-unreal)]

Confirm on my T61 with latest nvidia drivers. No change with Tribe 5 updates or others since.

[David MacKinnon (blaedd)]

This is _not_ an exact duplicate of #81407, and by marking is as duplicate, all the logs here are hidden, the other bug has not been updated in months.

As of g-p-m 2.19.6-0ubuntu2 brightness keys are now (kind of) working on the X60, but the OSD doesn't always display/update. Also, entering g-p-m settings resets the brightness to a bit below half way, which is really odd. Haven't tested yet on the T60p

[Andy Wang (andy-wang-603)]

I'm using X61 with Fesity installed.

when I use Fn+home/ Fn + end , there's flciker happening all the time, the birghtness OSD changes fast, it may become 100% quite fast then if you decrease, it may become black screen very fast.

Loaded the thinkpad_acpi module.

[Eddie Hung (eddieh)]

X41 (non tablet) owner here: and I've just upgraded to the latest 2.19.6-0ubuntu4 today - and I can now adjust the brightness of my laptop using the Fn keys, however, the GPM brightness indicator that pops up when I do is always either at zero, or at the one up from that. (This is better than it was previously - when previously pressing one direction would send it all the way to the maximum/minimum). However, dragging the brightness bar inside GPM results in the screen flickering very rapidly between full brightness and minimum brightness - as if the full range is every 10% of the bar. And related to that, after setting the desired brightness, and then moving between battery and AC results in the incorrect brightness being set. This is an improvement, I guess, because at the very least I can fall back onto my Fn keys now which act as expected. I would consider this a big and serious regression from Feisty, where the brightness worked fine - all except the gnome brightness indicator would not be in sync with the actual brightness when the Fn keys were used (however, the indicator would pop up, but its value wouldn't change) - and I really hope its sorted before release!

[Eddie Hung (eddieh)]

Spoke too soon - the brightness changes randomly, even though I'm not switching to/from AC, nor am I pressing the Fn keys. Downgraded back to 2.19.5-0ubuntu1.

[Brian Ealdwine (eode)]

I'm not entirely sure this is the exact same bug, however it seems that it is -- excepting that, in xev, I only get events when I hit the brightness adjusting keys.

In feisty, the behaviour of brightness on my machine was:
   On pressing brightness-up (fn-uparrow, fn-downarrow), I got random behaviour.

In gutsy, now, the behaviour is:
 * For brightness-up and down, xev reports a keypress/keyrelease event.
 * Nothing happens.
 * Keycode 101 on brightness down, and keycode 212 on brightness up.
 * XFilter event returns false

Interestingly, while I've heard that /proc/acpi/video/VGA/LCD/brightness should deal in values from 1-8 (I don't know if that's accurate or not), I get the following output from catting brightness:

/proc/acpi/video/VGA/LCD# cat brightness
levels: 100 37 12 25 37 50 62 75 87 100
current: 87

100 is listed twice.
100 is not a valid value. (bash: echo: write error: Invalid argument)
37 is listed twice.
37 is a valid value.
Brightness increases/decreases only on the specific values listed, within the range of 12 to 87.

My particular issue seems to be a kernel/video issue (or that that's a part of my issue) but that's a filtered group, so I can't post bugs there.

If this is a separate bug, I'll open a new report.

pastebin of xev output:
http://paste.ubuntu-nl.org/38132/

[toaste (toaste)]

I'm seeing similar behavior on a Dell Inspiron 1520. The brightness down button functions normally, but brightness up has no effect. The brightness meter appears, and the progress bar quickly increments and decrements back to the same position.

xev shows four keypress events with code 212 in quick succession in response to the brightness up key. A similar event occurs with four events with code 101 for down. Brightness immediately jumps to the preset for the current power state when opening the Gnome Power Management Applet.

[Joss Winn (josswinn)]

Similar problems on a Lenovo 3000 N100 0768FPG.

I can only set my brightness correctly with:

cat $level > /sys/class/backlight/acpi_video0/brightness

and then entering a number between 0 and 100.

There seems to be a patch here that works for someone:
http://<email address hidden>/msg08822.html

When I type:

cat $level > /sys/class/backlight/acpi_video0/brightness

I get this:

levels: 100 57 0 14 28 43 57 71 86 100
current: 0

despite having just set it at 100.

[misiu_mp (misiu-mp)]

I confirm this bug for Toshiba Satellite L40 (intel platform).

[Benjamin Emmel (bemmel)]

My Lenovo Thinkpad t60p has the same problem.

Marked as duplicate bug# 123548,

[icechen1 (houyuchen66)]

I confirm this with a Gateway MX6214.

[0x1DEA5 (0x1dea5)]

confirmed on Gateway MX6930

[donpdonp (don-park)]

i have a new thinkpad R61 with ubuntu 7.07.
the brightness function key works and i see the gnome UI element
to show the brightness lowering. it stays that way for about 30
seconds then something sends it back to 100% brightness.

[Marius Gedminas (mgedmin)]

FWIW LCD brightness works perfectly in the current Gutsy on my Lenovo T61. I previously had problems with it while Gutsy was still in development, but those problems seem to have been fixed.

[Brian Ealdwine (eode)]

Not here. Still have issues.

On Thu, 2008-02-21 at 17:51 +0000, Marius Gedminas wrote:
> FWIW LCD brightness works perfectly in the current Gutsy on my Lenovo
> T61. I previously had problems with it while Gutsy was still in
> development, but those problems seem to have been fixed.
>

[Pieter (diepes)]

I am having problems with the "Power Mangager Brightness Applet 2.21.91" when adjusting, it seems to freeze for a couple of seconds, and no change.

I can manually dim the screen with repeating the following in a xterm. echo 5 > /proc/acpi/ibm/cmos

lenovo R61 Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
2.6.24-11-generic
Hardy Heron

[phinn (phinn)]

I can confirm this bug on my Thinkpad T60. Running Ubuntu 7.10 (with all current fixes as of this date) and the power managment for the display is very buggy.

Mainly I want it to not dim unless not used for more than 5 minutes so when I'm reading something on battery power the display doesn't suddenly go to minimum brightness after like 30 seconds. But none of the Display settings in the power management seem to work at all.

[Joss Winn (josswinn)]

Confirmed here on Lenovo 3000 N100. On boot the display is fully dimmed and requires manual increase using the fn key. This has been occuring for a while now. Sorry I can't be more specific. Let me know if I can help debug. PM preferences don't seem to be working.

[cornbread (corn13read)]

Appears to be fixed on my x60 tablet

[Pedro Villavicencio (pedro)]

Thanks for the report David MacKinnon , It has been a long time without any comment or a duplicate in this bug report and It is possible that the bug has been fixed. May you please try to reproduce it with the latest Stable Release of Ubuntu the Natty Narwhal and add the respective comments to the report? You can learn how to get that release at http://www.ubuntu.com/download . Thanks again and we appreciate your help.

[Launchpad Janitor (janitor)]

[Expired for gnome-power-manager (Ubuntu) because there has been no activity for 60 days.]