Bug 41926

Could it be the same problem as with bug #41306?

I dont think so. this problems started just recently, after upgrading to fedora16 and so to kernel 3.1 and with intel_backlight control.

there are a lot of bugs reported, but i didnt find mine here. all think that the problem is with gnome-screensaver, but it happens as well with xset s activate, so basically my problem is that the driver should NOT touch backlight settings, unless the user wants to do so.

a screensaver may render the screen black, or it may turn the screen completely off, but he should not change the backlight settings. and of course, when he turns the monitor/lvds off, and the user comes back and hits a key or something, he should not only switch it on again (what he does) but also restore the backlight setting where thery were and not to 0%.

so.

i think i figured out where the problem was. all think that its a bug of gnome-screensaver, but that doesnt seem to have any energy saver feautures any more.

instead it seems to be xset dpms, so xorg itself that is either setting the backlight to zero and doesnt set it back when the user comes back, or it is the intel driver that is interpreting DPMS off as backlight set to 0%

I can confirm this bug on Acer 5740 laptop with Intel graphics.  I agree with Lars that the problem is most likely not in screensaver or power manager.  I am using neither one and "xset s activate" entered in a terminal window reproduces the behavior.

(In reply to comment #4)
> I can confirm this bug on Acer 5740 laptop with Intel graphics.  I agree with
> Lars that the problem is most likely not in screensaver or power manager.  I am
> using neither one and "xset s activate" entered in a terminal window reproduces
> the behavior.

of course ... i am not making here something up. that would be the last thing i would try after what i see happening around gnome3.

maybe i ll someday win a metal of reporting the most serious bugs around.

Lars, have you tried applying this patch https://lkml.org/lkml/2011/10/14/128 from Takashi Iwai to see if it fixes the problem?

(In reply to comment #6)
> Lars, have you tried applying this patch https://lkml.org/lkml/2011/10/14/128
> from Takashi Iwai to see if it fixes the problem?

well i know about that patch, but i am wondering why they do not apply it to the kernel, i am running fedora 16 with now kernel 3.1rc10 so i will wait for in when its applied to mainline, because such problem is not sustainable. it can not simply turn off the backlight and when i come back then do not remember what the last value was. that's a scandal...

(In reply to comment #6)
> Lars, have you tried applying this patch https://lkml.org/lkml/2011/10/14/128
> from Takashi Iwai to see if it fixes the problem?

well and that patch would not fix the problem, because i do not dim the backlight manually, it dims itself and my problem is that i do not want the driver to touch my backlight settings. when it wants to go to sleep, it can turn the whole device off power!!!

(In reply to comment #8)
> (In reply to comment #6)
> > Lars, have you tried applying this patch https://lkml.org/lkml/2011/10/14/128
> > from Takashi Iwai to see if it fixes the problem?
> 
> well and that patch would not fix the problem, because i do not dim the
> backlight manually, it dims itself and my problem is that i do not want the
> driver to touch my backlight settings. when it wants to go to sleep, it can
> turn the whole device off power!!!

OK, I just compiled and installed the 3.0.4 kernel with the above patch applied and as I suspected, it DOES in fact fix the problem.  Lars, since you opened the bug, you might want to try the patch yourself and report your results here.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > > Lars, have you tried applying this patch https://lkml.org/lkml/2011/10/14/128
> > > from Takashi Iwai to see if it fixes the problem?
> > 
> > well and that patch would not fix the problem, because i do not dim the
> > backlight manually, it dims itself and my problem is that i do not want the
> > driver to touch my backlight settings. when it wants to go to sleep, it can
> > turn the whole device off power!!!
> 
> OK, I just compiled and installed the 3.0.4 kernel with the above patch applied
> and as I suspected, it DOES in fact fix the problem.  Lars, since you opened
> the bug, you might want to try the patch yourself and report your results here.

calm down, if it really does fix that bug, i am happy. and as far i have no reason not to believe you. but dont push me.

i will take a closer look at it as soon as i get some time. in the meantime it should be cleared why the patch is not in the mainline. maybe some responsible ppl just do not know about it.

I updated to 3.1 kernel today with this patch applied: https://lkml.org/lkml/2011/10/2/185 from Alex Davis.  I did not apply the other patch mentioned above. Backlight is no longer set to 0 after resume from suspend or DPMS screen blank.

(In reply to comment #11)
> I updated to 3.1 kernel today with this patch applied:
> https://lkml.org/lkml/2011/10/2/185 from Alex Davis.  I did not apply the other
> patch mentioned above. Backlight is no longer set to 0 after resume from
> suspend or DPMS screen blank.

so the mainline 3.1 kernel does it w/o any patches?

(In reply to comment #11)
> I updated to 3.1 kernel today with this patch applied:
> https://lkml.org/lkml/2011/10/2/185 from Alex Davis.  I did not apply the other
> patch mentioned above. Backlight is no longer set to 0 after resume from
> suspend or DPMS screen blank.

well it looks like you applied another patch :-(

now the question remains which one will move into the mainline.

i will have some time, but i ll first wait for the 3.1 kernel w/ its sources to move to fedora16.

(In reply to comment #11)
> I updated to 3.1 kernel today with this patch applied:
> https://lkml.org/lkml/2011/10/2/185 from Alex Davis.  I did not apply the other
> patch mentioned above. Backlight is no longer set to 0 after resume from
> suspend or DPMS screen blank.

well i have tried that patch you mentioned, that one doesnt work for me, it seems that that patch is already in mainline and has no effect on my machine. problem still exists.

i am now going to test the other one.

Yes, when I went back and tested the first patch again, it did not work.  I believe I may have booted a different kernel than I thought I had during my initial test.  The second patch does work however and someone else confirmed it here: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/872652/comments/27

(In reply to comment #15)
> Yes, when I went back and tested the first patch again, it did not work.  I
> believe I may have booted a different kernel than I thought I had during my
> initial test.  The second patch does work however and someone else confirmed it
> here:
> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/872652/comments/27

well, i now have tested both of that patches ... none of it works.

even the one that was already reported to me as solving my problem here.

i thought that it sounds too good to be true. however, now we are back at the beginning. someone should write a functional driver/patch.

Sorry to hear that Lars.  It is interesting to note that Stefan Steffen Röcker
who confirmed the second patch works is also using a Macbook.

(In reply to comment #17)
> Sorry to hear that Lars.  It is interesting to note that Stefan Steffen Röcker
> who confirmed the second patch works is also using a Macbook.

now i waisted all my night by trying out the kernel 3.1 compiling it first took some time and then everytime patching and trying.

i could have seen it, because in those patches there was nothing in there that could fix this problem. i had that feeling as well.

the worst thing about this is, that even kernel or module parameters for i915 do not stop the driver from touching the backlight. so it must be somewhere hardcoded, because it can not be deactivated.

and this backlight problem may be some kind of a race condition in the code.

xset s activate or xset dpms force off do draw the backlight to 0% and dont bring it back after user comes back/is active.

the driver can not know who set the backlight to 0% if it was xorg or some backlight helper application.

xorg must make sure that after the user comes back, the backlight is on the old state and the driver should not remember some states, because he can not know what was set by screensaver and what by the user.

as long as xorg can draw the screen to 0% backlight, it can also bring it back because apparently ... the backlight controls are working. and working backlight control is the only thing this driver should do! and nothing more!

Why did you change the status of this bug to "NOTOURBUG"?  Who's bug do you think it is?

I understand your frustration with the way the driver works. Have you considered discussing it on LKML?

(In reply to comment #21)
> Why did you change the status of this bug to "NOTOURBUG"?  Who's bug do you
> think it is?
> 
> I understand your frustration with the way the driver works. Have you
> considered discussing it on LKML?

i think they do know what they are doing and the kernel developers do not care as much what applications do. there is no need to change something on the code, because as far it looks like backlight controls are working. so the problem is with xorg, because xorg does temper with the backlight settings and does not bring it back. and as long as there is no mechanism in the driver code that is holding xorg timers and user/applications calls apart, there is no need for some routines that save the current states of the backlight. the only exeption would be suspend-to-ram but that is working to me. when i wake my computer up from sleep and xorg did not tamper with the backlight in the meantime - so for example when i close the lid, it restores the backlight according to the setting that was set before.

(In reply to comment #22)

> some routines that save the current states of the backlight. the only exeption
> would be suspend-to-ram but that is working to me. when i wake my computer up
> from sleep and xorg did not tamper with the backlight in the meantime - so for
> example when i close the lid, it restores the backlight according to the
> setting that was set before.

Did you notice that closing and then opening the lid brings turns the backlight on even if power settings are NOT set to suspend on lid close? I think backlight level with change in lid state is handled differently than with mouse or keyboard activity after DPMS blanking.

(In reply to comment #23)
> (In reply to comment #22)
> 
> > some routines that save the current states of the backlight. the only exeption
> > would be suspend-to-ram but that is working to me. when i wake my computer up
> > from sleep and xorg did not tamper with the backlight in the meantime - so for
> > example when i close the lid, it restores the backlight according to the
> > setting that was set before.
> 
> Did you notice that closing and then opening the lid brings turns the backlight
> on even if power settings are NOT set to suspend on lid close? I think
> backlight level with change in lid state is handled differently than with mouse
> or keyboard activity after DPMS blanking.

that depends on your laptop. some machines simply dont care. for example on my acer aspire one AOA150 there is not even that problem with the screen blanking, because it handles its backlight for itself. and so should it be on all laptops, that such things are done by HW.

btw. downgrading to the kernel 3.0 or 2.6.39 does fix the problem.

(In reply to comment #25)
> btw. downgrading to the kernel 3.0 or 2.6.39 does fix the problem.

Could you bisect the kernel to the commit which introduced the regression for you?

(In reply to comment #26)
> (In reply to comment #25)
> > btw. downgrading to the kernel 3.0 or 2.6.39 does fix the problem.
> 
> Could you bisect the kernel to the commit which introduced the regression for
> you?

no. it is more simple. 3.0 still doesnt use intel_backlight, there is only apple_backlight and that one works perfectly.

for me intel_backlight did not ever work.

In Ubuntu 11.10 we ship a backport of intel_backlight in our 3.0-based kernel, and we do also see this problem, as noted in https://launchpad.net/bugs/872652 .

I confirm that Alex Davis's patch https://lkml.org/lkml/2011/10/2/185 fixes it for my Dell Studio 1558.

(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > btw. downgrading to the kernel 3.0 or 2.6.39 does fix the problem.
> > 
> > Could you bisect the kernel to the commit which introduced the regression for
> > you?
> 
> no. it is more simple. 3.0 still doesnt use intel_backlight, there is only
> apple_backlight and that one works perfectly.
> 
> for me intel_backlight did not ever work.

that would be commit aaa6fd2a004147bf32fce05720938236de3361d9

(In reply to comment #28)
> In Ubuntu 11.10 we ship a backport of intel_backlight in our 3.0-based kernel,
> and we do also see this problem, as noted in https://launchpad.net/bugs/872652
> .
> 
> I confirm that Alex Davis's patch https://lkml.org/lkml/2011/10/2/185 fixes it
> for my Dell Studio 1558.

well but that patch does what? does the same. it comments out or disables some routines. so that would be about the same as downgrading.

(In reply to comment #30)
> (In reply to comment #28)
> > In Ubuntu 11.10 we ship a backport of intel_backlight in our 3.0-based kernel,
> > and we do also see this problem, as noted in https://launchpad.net/bugs/872652
> > .
> > 
> > I confirm that Alex Davis's patch https://lkml.org/lkml/2011/10/2/185 fixes it
> > for my Dell Studio 1558.
> 
> well but that patch does what? does the same. it comments out or disables some
> routines. so that would be about the same as downgrading.

Not really.  The patch does not remove intel_backlight, it just prevents the backlight level from being recorded as zero when DPMS is activated.

(In reply to comment #30)
> > 
> > I confirm that Alex Davis's patch https://lkml.org/lkml/2011/10/2/185 fixes it
> > for my Dell Studio 1558.
> 
> well but that patch does what? does the same. it comments out or disables some
> routines. so that would be about the same as downgrading.

Not at all.  The Alex Davis patch removes just one line; the new intel_backlight interface remains fully functional.


(In reply to comment #31)
> it just prevents the
> backlight level from being recorded as zero when DPMS is activated.

My reading is that it prevents the backlight from being explicitly set to zero when DPMS is activated.

(In reply to comment #32)
> (In reply to comment #30)
> > > 
> > > I confirm that Alex Davis's patch https://lkml.org/lkml/2011/10/2/185 fixes it
> > > for my Dell Studio 1558.
> > 
> > well but that patch does what? does the same. it comments out or disables some
> > routines. so that would be about the same as downgrading.
> 
> Not at all.  The Alex Davis patch removes just one line; the new
> intel_backlight interface remains fully functional.
> 
> 
> (In reply to comment #31)
> > it just prevents the
> > backlight level from being recorded as zero when DPMS is activated.
> 
> My reading is that it prevents the backlight from being explicitly set to zero
> when DPMS is activated.

well it did not fit my kernel. maybe it will be applied to the mainline someday.

however ... the backlight is set to 0 also on xset s activate. so it doesnt help to just say, well, when you are off then do not record the backlight level as zero, as long as xorg says that it is 0 before it gets off. you have the same problem after.

(In reply to comment #33)
> 
> however ... the backlight is set to 0 also on xset s activate. so it doesnt
> help to just say, well, when you are off then do not record the backlight level
> as zero, as long as xorg says that it is 0 before it gets off. you have the
> same problem after.

I find that Alex Davis's patch fixes the "xset s activate" behavior on my system as well.  Before applying the patch, "xset s activate" would switch off the backlight and leave it stuck off.  After applying the patch, "xset s activate" behaves normally again.

(In reply to comment #34)
> (In reply to comment #33)
> > 
> > however ... the backlight is set to 0 also on xset s activate. so it doesnt
> > help to just say, well, when you are off then do not record the backlight level
> > as zero, as long as xorg says that it is 0 before it gets off. you have the
> > same problem after.
> 
> I find that Alex Davis's patch fixes the "xset s activate" behavior on my
> system as well.  Before applying the patch, "xset s activate" would switch off
> the backlight and leave it stuck off.  After applying the patch, "xset s
> activate" behaves normally again.

well, that would be a good news then. but i ve heard that so many times before.

however. i am now running 3.0 kernel. and we will see what happens after the 3.1, maybe it gets rewritten, or at least they apply that patch or the best would be to make that intel-backlight optional, so that it can be disabled. that would be the best option. so we could try it out and leave it when it works or disable it and get on with the old way.

but for developers, these discussions are irrelevant. i ll make the proposal to the developer(s) who are in charge to make that intel_backlight an option for the module, so that it can be disabled. thats the only way we can move something. arguing here about little differences doesnt help.

Looking back to kernel 2.6.37, commit 47356eb67285014527a5ab87543ba1fae3d1e10a actually introduced the line of code that is patched by https://lkml.org/lkml/2011/10/2/185 .  So it appears the intel native backlight driver commit aaa6fd2a004147bf32fce05720938236de3361d9 did not cause the problem but did expose it.

A patch referencing this bug report has been merged in Linux v3.2-rc3:

commit 04b38670cf46c096705f24e92a8747d1ab89e53c
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Nov 16 10:58:03 2011 +0100

    drm/i915: Fix inconsistent backlight level during disabled