Bug 913722

Summary: Laptop brightness flickers spuriously on its own after a suspend/resume
Product: [Fedora] Fedora Reporter: Tommi Kyntola <kynde>
Component: kde-workspaceAssignee: Lukáš Tinkl <ltinkl>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 18CC: dvratil, jgrulich, jreznik, kevin, ltinkl, mbriza, mspaulding06, rdieter, rnovacek, than
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: 4.10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-11 08:20:12 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 907993    
Bug Blocks:    

Description Tommi Kyntola 2013-02-21 16:59:45 EST
Description of problem:
Upon resume from suspend the brighness dances back and forth furiously between some two values, e.g. 40% and 80%. Sometimes it stops on it's own after a second or two, sometimes only after I adjust it (although never immediately, i.e. it flickers even after a few presses, but range of flicker does change).

Version-Release number of selected component (if applicable):
Fully updated F18 running KDE. This has been present on this Lenovo X1 carbon since I first installed F18 onto this one Jan 24th.

How reproducible:
So and so, happens once every ten to twenty suspend cycles.

Steps to Reproduce:
1. suspend with lid
2. resume by opening up the lid
Actual results:
The screen brightness controls flicker between two values furiously without me touching them, just as if I were pressing the buttons back and forth. As if two different mechanisms keep twidling with them. Nothing spurious is printed to /var/log/messages during it.

Expected results:
Screen brightness wouldn't flicker.

Additional info:
I haven't come up with a simple trick to overcome it. I've tried pressing keys, touching touchpad, brightness controls, switching to tty2 and some others. But it happens too rarely and mostly when I'm at work and don't have the time investigate it. I'm guessing some of those adjustments made by whoever are queued and that makes it difficult for me to spot whether making brightness adjustments and tty switching helps or not. Hard to say.

The suspend/resume cycle has been buggy with F18 on this laptop since the day one, because of double suspends, but that's being dealt with in bug 859227.
I have now disabled lid switch handling from logind.conf to fix the double suspend, but the flickering persists.

I couldn't find a related bug from the bugzilla, but sorry if this a dupe or a known issue.
Comment 1 Tommi Kyntola 2013-02-21 17:22:04 EST
Ok, plot thickens. Right after submitting that I started watching a movie with the laptop. The brightness again behaves oddly, the brightness bar drops down to half, yet it shows 100% and the brightness remains fully on. Battery well over 70%. It does that a few times every few minutes and then it starts the same freaking flickering. Adjusting the brightness didn't alleviate the issue, I switched to tty2 and the screen kept flickering even while there but did stop as I got back to X. Odd.
Comment 2 Matt Spaulding 2013-03-04 10:45:58 EST
I'm also seeing this on my laptop.

Lenovo Thinkpad X220
Fedora 18
Latest KDE Packages

When plugging in power to my laptop it will switch rapidly between 60% (brightness set when unplugged) and 100% (brightness when plugged in) for upwards of a minute. It only happens sometimes; usually the first time I plug in power after a reboot.
Comment 3 Matt Spaulding 2013-03-04 10:53:50 EST
Found some additional information with possible solution to the issue:
Comment 4 Rex Dieter 2013-03-04 10:56:27 EST
interesting, ubuntu reverted some upstream commit.  looking to see what it was...
Comment 5 Rex Dieter 2013-03-04 10:58:12 EST

"emit onBrightnessChanged every time when a new brightness gets set and
not just on brightnessKey press"

I'm not keen on taking the same approach of reverting this.
Comment 6 Kevin Kofler 2013-03-04 11:51:33 EST
I think reverting this is sane. Do we really need the brightness OSD popping up when you (say) plug/unplug your notebook from power? I've found this odd ever since it got implemented.

If you do like the feature, it should get some recursion guards added so it stops causing infinite recursion. onBrightnessChanged must not change the brightness, or at least not in a way which triggers another onBrightnessChanged event.
Comment 7 Lukáš Tinkl 2013-03-09 09:14:15 EST
Can you retry with KDE 4.10?
Comment 8 Tommi Kyntola 2013-03-10 16:00:55 EDT
I have, 4.10.1-1 from testing seems to work ok. I haven't had a flickering issue since I upgraded to it on three days ago.
Comment 9 Rex Dieter 2013-03-10 16:22:21 EDT
As a matter of fact, I too used to see this from time to time, but it's been a long while, esp not since I'd upgraded to 4.10 myself.
Comment 10 Lukáš Tinkl 2013-03-11 08:20:12 EDT
This is indeed fixed in KDE 4.10