Bug 22672 - Regression in 2.6.37-rc1 for Intel 945 Graphics Adapter - bisected to commit e9e331a
Summary: Regression in 2.6.37-rc1 for Intel 945 Graphics Adapter - bisected to commit ...
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
URL:
Keywords:
: 23122 25562 26602 (view as bug list)
Depends on:
Blocks: 21782
  Show dependency tree
 
Reported: 2010-11-11 01:56 UTC by Larry Finger
Modified: 2011-09-02 08:04 UTC (History)
25 users (show)

See Also:
Kernel Version: 2.6.37-rc1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Fix backlight_level accounting. (1.96 KB, patch)
2011-01-10 12:06 UTC, Indan
Details | Diff
Check for (pfit_control & PFIT_ENABLE) instead of pfit_control only. (807 bytes, patch)
2011-01-11 09:32 UTC, Indan
Details | Diff
Count backlight enable/disable (5.63 KB, patch)
2011-01-11 17:45 UTC, Chris Wilson
Details | Diff

Description Larry Finger 2010-11-11 01:56:58 UTC
On my HP Mini 110 netbook with an Intel 945GME graphics adapter and kernel
2.6.37-rc1, screen blanking has a problem. On this machine, the screen is
blanked in two stages. The first leaves the backlight on, the second turns the
backlight off.

The details of the graphics adapter are as follows:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME
Express Integrated Graphics Controller [8086:27ae] (rev 03)
        Subsystem: Hewlett-Packard Company Device [103c:308f]
        Kernel driver in use: i915
00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME,
943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
        Subsystem: Hewlett-Packard Company Device [103c:308f]


Beginning with commit e9e331a8abeece1565d383510ed985945132ffe3 as determined
with bisection, the system no longer reawakens from the second stage with mouse
movements or key presses. The only way to bring it back that I have found is to
close the cover. After reopening the cover and entering the password to unlock
the system, the screen is restored.

The commit message is:

Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Sep 13 01:16:10 2010 +0100

    drm/i915/lvds: Ensure panel is unlocked for Ironlake or the panel fitter

    Commit 77d07fd9d73ef28689737c0952dbd5d6a5017743 introduced a regression
    where by not waiting for the panel to be turned off, left the panel and
    PLL registers locked across the modeset. Thus the panel remaining blank.

    As pointed out by Daniel Vetter, when testing LVDS it helps to open the
    laptop and look at the actual panel you are purporting to test.

    A second issue with the patch was that in order to modify the panel
    fitter before gen5, the pipe and the panel must have be completely
    powered down. So we wait.
Comment 1 Larry Finger 2010-11-11 03:45:03 UTC
Additional information:

In intel_lvds_prepare(), the else if (intel_lvds->pfit_dirty) branch is taken, thus HAS_PCH_SPLIT() is false.
Comment 2 Alex Riesen 2010-11-11 21:38:09 UTC
I think I have the same problem:

00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
	Subsystem: Dell Device 0209
	Flags: bus master, fast devsel, latency 0
	Memory at f6f00000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: <access denied>

agpgart-intel 0000:00:00.0: Intel 965GM Chipset
agpgart-intel 0000:00:00.0: detected gtt size: 524288K total, 262144K mappable
agpgart-intel 0000:00:00.0: detected 8192K stolen memory

Just reported it on LKML: http://marc.info/?l=linux-kernel&m=128950985131154&w=2

Sadly, I cannot test the commit by simply reverting it: the conflict is not
trivial enough for me.
Comment 3 Rafael J. Wysocki 2010-11-19 20:34:04 UTC
On Friday, November 19, 2010, Larry Finger wrote:
> On 11/18/2010 05:42 PM, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.36.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=22672
> > Subject             : Regression in 2.6.37-rc1 for Intel 945 Graphics
> Adapter - bisected to commit e9e331a
> > Submitter   : Larry Finger <Larry.Finger@lwfinger.net>
> > Date                : 2010-11-11 01:56 (8 days old)
> 
> This bug is not yet fixed.
Comment 4 arond 2010-11-24 00:50:04 UTC
I think I have the same, as well on 945GME. Still present in 2.6.37-rc3... 

and (as lid status is broken for me) I have to suspend to ram and come back to get the light back on...:)
Comment 5 Søren Holm 2010-11-29 12:57:22 UTC
I have the same issue usign this card

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

I get backlight back againg by closing and opening the lid.
Comment 6 Florian Mickler 2010-11-30 11:36:59 UTC
*** Bug 23122 has been marked as a duplicate of this bug. ***
Comment 7 Florian Mickler 2010-11-30 11:38:25 UTC
Nick Bowler wrote at Bug #23122:
> I filed a very similar bug upstream before finding this one; while the
> symptoms are not identical, I bisected it to the same commit:
> 
>   https://bugs.freedesktop.org/show_bug.cgi?id=31803

References: https://bugs.freedesktop.org/show_bug.cgi?id=31803
Comment 8 Florian Mickler 2010-11-30 11:39:00 UTC
References: http://marc.info/?l=linux-kernel&m=128944001311444&w=2
Comment 9 Søren Holm 2010-12-02 20:24:15 UTC
Bug is still present en 2.6.37-rc4
Comment 10 Rafael J. Wysocki 2010-12-02 21:02:40 UTC
*** Bug 23472 has been marked as a duplicate of this bug. ***
Comment 11 Rafael J. Wysocki 2010-12-03 21:30:04 UTC
On Friday, December 03, 2010, Larry Finger wrote:
> On 12/02/2010 05:41 PM, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > from 2.6.36.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=22672
> > Subject             : Regression in 2.6.37-rc1 for Intel 945 Graphics
> Adapter - bisected to commit e9e331a
> > Submitter   : Larry Finger <Larry.Finger@lwfinger.net>
> > Date                : 2010-11-11 01:56 (22 days old)
> 
> Still present in -rc4.
Comment 13 Alex Riesen 2010-12-05 18:36:34 UTC
(In reply to comment #12)
> References:
> http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg02235.html
> 
> Patch: https://patchwork.kernel.org/patch/359472/
> Patch: https://patchwork.kernel.org/patch/359502/

My tree has both these patches (they are in Linus' tree since 1st december).
They don't fix the issue on my laptop (Dell XPS M1330).
Comment 14 Larry Finger 2010-12-05 21:30:15 UTC
They do not fix my problem either. The bug report is reopened.
Comment 15 Hans de Bruin 2010-12-05 22:28:51 UTC
My Dell D430 has similar issues. It does not matter in which mode kde puts the screen: standby, suspend or power off. In all cases the back light stays on (i have never seen it off). When the screen is 'unblanked' it returns in the lowest possible brightness level, and with dis-functional brightness keys (separate key's on the keyboard to change the brightness). Closing and reopening the lid restores the brightness to maximum level and restores the function of the brightness keys. I have bisected the problem to the same commit as above. I rebuild linus's tree every day, and the bug is still there.
Comment 16 Florian Mickler 2010-12-06 16:23:52 UTC
There is a corresponding userspace driver fix on the xf86-video-intel master branch at git://anongit.freedesktop.org/xorg/driver/xf86-video-intel which comes with those two patches. 

commit 33c08882c0d551afb28baef643279901dcc65fa9
Author: Keith Packard <keithp@keithp.com>
Date:   Wed Nov 17 16:37:53 2010 +0800

    Mark outputs as DPMSModeOn and restore backlight at mode set
    
    The kernel always turns monitors on when doing mode setting, and so no
    further DPMS action is required. Note this in the mode setting code by
    marking the updated DPMS mode and restoring any saved backlight level.
    
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Reviewed-by: Eric Anholt <eric@anholt.net>
Comment 17 Søren Holm 2010-12-08 12:14:21 UTC
It is still a problem in 2.6.37-rc5.
Comment 18 Alex Riesen 2010-12-19 10:42:05 UTC
Still broken in 2.6.37-rc6
Comment 19 Larry Finger 2010-12-19 16:05:30 UTC
Unfortunately, yes it is still broken in -rc6.
Comment 20 Rafael J. Wysocki 2010-12-19 18:55:09 UTC
On Sunday, December 19, 2010, Larry Finger wrote:
> On 12/19/2010 06:34 AM, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.36.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=22672
> > Subject             : Regression in 2.6.37-rc1 for Intel 945 Graphics
> Adapter - bisected to commit e9e331a
> > Submitter   : Larry Finger <Larry.Finger@lwfinger.net>
> > Date                : 2010-11-11 01:56 (39 days old)
> 
> The problem is still present in 2.6.37-rc6.
Comment 21 Søren Holm 2010-12-25 15:25:02 UTC
Merry Christmas everybody.

As of today this is still present in current master.
Comment 22 Alex Riesen 2010-12-29 10:28:02 UTC
Still broken in -rc8.

http://marc.info/?t=129358572400001&r=1&w=4
Comment 23 Søren Holm 2010-12-29 17:00:37 UTC
Broken for me too in rc8
Comment 24 Hans de Bruin 2010-12-29 18:06:39 UTC
The back light of my Dell D430 now is turned of when the screen blanks. I don't know at which rc this feature became active. The screen still recovers in the lowest possible brightness level, and with dis-functional brightness keys.
Comment 25 Rafael J. Wysocki 2010-12-30 10:57:58 UTC
On Thursday, December 30, 2010, Larry Finger wrote:
> On 12/29/2010 05:06 PM, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.36.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=22672
> > Subject             : Regression in 2.6.37-rc1 for Intel 945 Graphics
> Adapter - bisected to commit e9e331a
> > Submitter   : Larry Finger <Larry.Finger@lwfinger.net>
> > Date                : 2010-11-11 01:56 (49 days old)
> 
> Neither 2.6.37-rc8 nor the patches listed above fix my system.
Comment 26 Rafael J. Wysocki 2010-12-30 10:58:58 UTC
Ignore-Patch: https://patchwork.kernel.org/patch/359472/
Ignore-Patch: https://patchwork.kernel.org/patch/359502/
Comment 27 Alex Riesen 2011-01-01 19:56:49 UTC
Still broken in the master tree after Linus merged all the reverted i915 commits
(by Chris Wilson, 3643e0e87c13c670a).
Comment 28 Martin 2011-01-02 08:52:40 UTC
Still broken for me on 2.6.37-rc8-git1 (2010-12-31).

HW: Dell vostro 1400,

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
Comment 29 Martin 2011-01-06 10:09:07 UTC
Bug is still present in 2.6.37 mainline for me.
Comment 30 Roman 2011-01-06 14:06:21 UTC
Got the same problem on my Samsung NP-X120 laptop with GM45 chipset on mainline 2.6.37. 

xf86-video-intel 2.13
xorg-server 1.9.2
Comment 31 Roman 2011-01-06 19:23:42 UTC
The problem is also present on mainline 2.6.37 with the following:

xf86-video-intel 2.13.903
xorg-server 1.9.2.902
Comment 32 russell bell 2011-01-07 21:34:55 UTC
Beginning with mainline 2.6.37 my screen goes permanently blank when the i915 driver loads and switches the video mode to 48x170.  Everything else works.  Logs report no problems, nothing different than when I run 2.6.36 (my previous version).

Linux version 2.6.37 (russell@randytool.net) (gcc version 4.5.1 (GCC) ) #1 SMP Thu  Jan 6 18:23:51 MST 2011

VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Device 0212

i915

in an emachines E725 laptop.
Comment 33 Indan 2011-01-10 12:06:15 UTC
Created attachment 43132 [details]
Fix backlight_level accounting.

I think I've more or less figured out what's wrong, or at least a fix for it. The real problem could be that there's way too much unnecessary backlight setting going on, but this patch tries to make that more harmless.

The problem is that intel_lvds_disable() is called too often, or at least more than once for each intel_lvds_enable() call (it looks like it's called twice for each enable call). This should be harmless, but because the current backlight level is stored unconditionally, the real value gets overwritten by zero.

I suspect this regression was caused by a change that introduced the extra intel_lvds_disable() call. If someone wants to look into that, they probably have to look around drm/i915/intel_display.c:intel_crtc_dpms() and drm/drm_crtc_helper.c:drm_helper_connector_dpms().

The patch is against 2.6.37 and also fixes intel_lvds_prepare() and intel_lvds_commit() to behave more sensibly.

Signed-of-by: Indan Zupancic <indan@nul.nu>
Comment 34 Antony.PS 2011-01-10 16:55:21 UTC
I have found a workaround for my Acer Aspire 5732Z:
echo '/usr/sbin/setpci -s 00:02.0 F4.B=00' >> /etc/rc.local
Comment 35 Hans de Bruin 2011-01-10 20:55:29 UTC
(In reply to comment #33)
> Created an attachment (id=43132) [details]
> Fix backlight_level accounting.
> 
...

The patch fixes the problem on my Dell D430.

-- 
Hans
Comment 36 Larry Finger 2011-01-11 03:34:23 UTC
It does not fix the original problem noted for this bug.

When my system blanks the screen completely - a two step process, the only way to get it back is to close the cover. Mouse and keyboard activity does nothing.
Comment 37 russell bell 2011-01-11 04:59:01 UTC
/sbin/setpci -s 00:02.0 F4.B=00 works for me; I put it at the end of rc.modules
Comment 38 Indan 2011-01-11 09:32:20 UTC
Created attachment 43242 [details]
Check for (pfit_control & PFIT_ENABLE) instead of pfit_control only.

(In reply to comment #36)
> It does not fix the original problem noted for this bug.

Did you try both my path, and the setpci thing?

> When my system blanks the screen completely - a two step process, the only
> way
> to get it back is to close the cover. Mouse and keyboard activity does
> nothing.

If you tilt the laptop and look very closely, can you see stuff on the screen? I could, the screen turned on but the backlight stayed off. It would be interesting to know if nothing at all happens or if it's just the backlight.

Also, does the brightness level always get restored correctly or is it sometimes set to the highest setting, or too dim?

To get more info, you could run with drm.debug=0x02 or so, and try to spot anything weird happening. (Maybe you want the kms one, debug=0x04. For an explanation you have to read drmP.h.) Your kernel buffer will be flooded (maybe boot with log_buf_len=1M), so compare dmesg just before and after running:

"xset dpms force off; sleep 1; xset dpms force on"

And then close and open the lid to see what happened. Then compare what resume does to what dpms does. (I'd start with grepping for "lvds".)

> In intel_lvds_prepare(), the else if (intel_lvds->pfit_dirty) branch is
> taken,
> thus HAS_PCH_SPLIT() is false.

That pfit_dirty is set seems relevant. I'm not sure what it means though. What is your monitor's native screen resolution and what resolution are you using?

Looking at the code, I can see two potential problems, attached a patch that tries to fix them. Even if this doesn't fix anything, I still wonder if this patch shouldn't be applied anyway.

Before you waste a lot of time doing other stuff, I'd try this patch (on top of the previous one).
Comment 39 Larry Finger 2011-01-11 15:50:45 UTC
Applying the 2 patches fixes my system. The setpci business is not needed.

I'm going to assume that fixing the problem makes the answers to the above questions irrelevant. If not, let me know and I will supply that information.

Thanks for keeping on this problem.

For the record, the kernel that I tested is no longer vanilla 2.6.37, but is tracking the .37 => .38 merge. The git describe command lists it as v2.6.37-3737-g0c21e3a. I don't think there have been any i915 changes in the updates.
Comment 40 Roman 2011-01-11 16:26:21 UTC
Confirming fix.
These two patches restore correct LVDS behavior on my Samsung NP-X120 laptop with mainline 2.6.37.
Comment 41 Michal Hocko 2011-01-11 17:14:10 UTC
The two patches fix my 'xset dpms force standby; sleep 1; xset dpms force on' problem as well.
Comment 42 Chris Wilson 2011-01-11 17:45:34 UTC
Created attachment 43272 [details]
Count backlight enable/disable

It is indeed possible for intel_lvds_disable to be called more often than intel_lvds_enable, due to some fun interactions in drm_kms_helper. It shouldn't but it does.

So we have to track the backlight enable/disable more carefully.

The panel fitting patch looks like it will break switching between non-native resolutions. It should reduce to:


diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds
index 3538e6b..40e1e87 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -371,6 +371,8 @@ static bool intel_lvds_mode_fixup(struct drm_encoder *encode
        }
 
 out:
+       if ((pfit_control & PFIT_ENABLE) == 0)
+               pfit_control = 0;
        if (pfit_control != intel_lvds->pfit_control ||
            pfit_pgm_ratios != intel_lvds->pfit_pgm_ratios) {
                intel_lvds->pfit_control = pfit_control;
Comment 43 Larry Finger 2011-01-11 17:57:11 UTC
Color me "confused". What combination of patches should be tested?
Comment 44 Chris Wilson 2011-01-11 18:14:32 UTC
As the report is that both patches are required, the question becomes just what is wrong with the current method of disabling the pfit. The docs say that the requirement is that the panel must be off ((PP_STATUS & PP_ON) == 0) before the pfit can be modified. So from that perspective it looks like the code should not be causing harm. So I am interested in just what values we are programming into pfit_control in lvds_disable() that causes the panel to die.
Comment 45 Michal Hocko 2011-01-11 18:36:49 UTC
I have retested with the 1st patch only and it works just fine. So it looks that the second one is not necessary for the proper 
xset dpms force standby; sleep 1; xset dpms force on

usecase
Comment 46 Alex Riesen 2011-01-11 18:53:30 UTC
Dell XPS M1330 (GM965/GL960). The 1st patch fixed backlight after panel suspend here also. The 2nd doesn't seem to change anything.

If I max out the backlight, than close and open the lid, the brightness goes one step dimmer; IOW I have to press the button exactly once to restore the brightness to maximum.
Comment 47 Larry Finger 2011-01-11 19:30:23 UTC
To answer my own question from Comment #43, only the 3rd patch was needed to fix my box.

With that patch and today's pull from Linux-2.6.git, the screen is restored from full blanking by mouse or keyboard action. The brightness is restored to the value it was before blanking. Everything looks good here.
Comment 48 Alex Riesen 2011-01-11 20:12:48 UTC
Chris' patch (Count backlight enable/disable) fixes both backlight after
suspend issue and that "1 step dimmer after lid close/open" I reported in #46.

Tested with vanilla 2.6.37
Comment 49 Darisuz Luksza 2011-01-12 09:37:13 UTC
I had similar problem on my Toshiba R700 laptop with i5 processor. Details of the graphic adapter are:

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0007
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3050 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915

I have tested Cris' patch and it doesn't fix this problem.
Comment 50 Chris Wilson 2011-01-12 10:50:23 UTC
(In reply to comment #49)
> I had similar problem on my Toshiba R700 laptop with i5 processor. Details of
> the graphic adapter are:

Similar, but definitely not the same. Is it an eDP display perchance?
This bug is only on gen3/gen4 (i915-i965 gpus).
Comment 51 Michal Hocko 2011-01-12 11:14:23 UTC
The patch from comment 42 on top of .37 fixes the problem as well.
Comment 52 Darisuz Luksza 2011-01-12 12:14:07 UTC
(In reply to comment #50)
> Similar, but definitely not the same. Is it an eDP display perchance?

To be honest, I don't know that. How can I check if it is eDP (embedded Display Port, as far as I understood this acronym) ?
Comment 53 Chris Wilson 2011-01-12 12:17:54 UTC
xrandr or Xorg.log
Comment 54 Darisuz Luksza 2011-01-12 12:23:21 UTC
(In reply to comment #53)
> xrandr or Xorg.log

xrandr shows that LVDS1 output is connected and there are also additional not connected outputs like: VGA1, DP1, DP2, HDMI1 and HDMI2
Comment 55 Chris Wilson 2011-01-12 12:29:49 UTC
(In reply to comment #54)
> (In reply to comment #53)
> > xrandr or Xorg.log
> 
> xrandr shows that LVDS1 output is connected and there are also additional not
> connected outputs like: VGA1, DP1, DP2, HDMI1 and HDMI2

Ok, if drm-intel-staging also fails, can you please file a new bug report with drm.debug=0xe dmesg, Xorg.log, xrandr --verbose and intel_reg_dumper (before i915.ko loads and afterwards)?
Comment 56 Darisuz Luksza 2011-01-12 12:40:07 UTC
(In reply to comment #55)
> Ok, if drm-intel-staging also fails, can you please file a new bug report
> with
> drm.debug=0xe dmesg, Xorg.log, xrandr --verbose and intel_reg_dumper (before
> i915.ko loads and afterwards)?

Where can I find drm-intel-staging?
Comment 58 Patrick Schaaf 2011-01-12 15:48:33 UTC
(In reply to comment #42)
> Created an attachment (id=43272) [details]
> Count backlight enable/disable

Hi Chris,

I tried that patch, instead of the "return 0;" thing from Indan's first attempt.
Applied with one shifted hunk on vanilla 2.6.37.

I can CONFIRM that it FIXES the backlight dimming issues I've seen on my Dell laptop.

Thanks!

Patrick
Comment 59 Chris Wilson 2011-01-12 16:21:39 UTC
*** Bug 23472 has been marked as a duplicate of this bug. ***
Comment 60 Chris Wilson 2011-01-12 19:49:47 UTC
*** Bug 25562 has been marked as a duplicate of this bug. ***
Comment 61 Rafael J. Wysocki 2011-01-12 19:55:01 UTC
*** Bug 26602 has been marked as a duplicate of this bug. ***
Comment 62 Chris Wilson 2011-01-14 17:06:53 UTC
Ok, this particular patch is upstream, though we still have a broken backlight in combination mode and ACPI issues.
Comment 63 kees_lemmens 2011-01-23 17:37:30 UTC
(In reply to comment #15)
> My Dell D430 has similar issues. It does not matter in which mode kde puts
> the
> screen: standby, suspend or power off. In all cases the back light stays on
> (i
> have never seen it off). When the screen is 'unblanked' it returns in the
> lowest possible brightness level, and with dis-functional brightness keys
> (separate key's on the keyboard to change the brightness). Closing and
> reopening the lid restores the brightness to maximum level and restores the
> function of the brightness keys. I have bisected the problem to the same
> commit
> as above. I rebuild linus's tree every day, and the bug is still there.

I had similar backlight problems on my Dell D430 and kernel 2.6.36.2. After suspend the brightness keys would fail and the backlight was in a very low state, making the screen hard to read.

I solved it however not by patching the kernel but by adding the following boot option to my /etc/lilo.conf (or grub if you prefer) :

append="video.allow_duplicates=1"

This seems to fix the problem completely and now the backlight is fine
after a restore. Also, now there are 2 lines in dmesg after a restore :

 video LNXVIDEO:00: Restoring backlight state
 video LNXVIDEO:01: Restoring backlight state

while without the boot option there would be only 1 line in dmesg :

 video LNXVIDEO:00: Restoring backlight state

FYI: the option was suggested by the kernel itself :

Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.

regards,
Kees Lemmens.
Comment 64 Kees Lemmens 2011-01-24 11:35:05 UTC
Hi,

False alarm : problem is NOT solved with video.allow_duplicates=1. But the problem can be easily avoided in anaoter way : the backlight is ONLY frozen in a low state if a do a suspend and then CLOSE THE LID WHILE IT IS SUSPENDING !

If I first suspend to ram and only close the lid when the system is suspended the backlight is fine after a restore. 

Probably the acpi action for closing the lid and the action for suspend are biting each other if the coincide ?

regards,
Kees Lemmens.
Comment 65 Kees Lemmens 2011-01-24 11:36:23 UTC
Hi,

False alarm : problem is NOT solved with video.allow_duplicates=1. But the problem can be easily avoided in anaoter way : the backlight is ONLY frozen in a low state if a do a suspend and then CLOSE THE LID WHILE IT IS SUSPENDING !

If I first suspend to ram and only close the lid when the system is suspended the backlight is fine after a restore. 

Probably the acpi action for closing the lid and the action for suspend are biting each other if the coincide ?

regards,
Kees Lemmens.
Comment 66 Indan 2011-01-24 23:42:26 UTC
Kees, this particular problem is fixed upstream already. It was a bug in the 
code, perhaps revealed because of different behaviour than before, but still 
a bug. You can try to work around the bug, but that doesn't solve it.

The reason lid closing makes a difference is because when you close the lid
the screen gets blanked before you suspend and you hit this particular bug. 
If you don't close the lid you have normal suspend resume, which apparently 
works for you.

This particular bug is about screen blanking, not backlight problems after 
suspend.
Comment 67 Martin 2011-01-25 11:30:42 UTC
Will this fix be applied to 2.6.37.1 or do I have to wait for 2.6.38?
Comment 68 arond 2011-01-27 10:19:23 UTC
It seems fixed to me on 2.6.38-rc2-1. Thanks!
Comment 69 Martin 2011-01-29 18:58:53 UTC
I'm trying 2.6.38-rc2 atm and for me it's nearly fixed: "xset dpms force off; sleep 1; xset dpms force on" brings back the backlight half-decent, but the good thing is I can restore the brightness to full again using the HW keys on my laptop.
Comment 70 Indan 2011-01-29 22:21:01 UTC
Martin, does the same happen after a suspend? Perhaps you're hitting bug 23472: If so, you could try either my "fix_combination_mode" or "remove_is_backlight_combination_mode" patch (perhaps after some modifications for rc1, patch is against 37). Please report at bug 23472 instead of here if it makes any difference.
Comment 71 Vlad 2011-09-02 08:04:01 UTC
This patch does not work if the backlight level is set at a maximum.
agpgart-intel 0000:00:00.0: Intel GM45 Chipset
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)

Note You need to log in before you can comment on or make changes to this bug.