Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Laptop brightness flickers spuriously on its own after a suspend/resume|
|Product:||[Fedora] Fedora||Reporter:||Tommi Kyntola <kynde>|
|Component:||kde-workspace||Assignee:||Lukáš Tinkl <ltinkl>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||dvratil, jgrulich, jreznik, kevin, ltinkl, mbriza, mspaulding06, rdieter, rnovacek, than|
|Fixed In Version:||4.10||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-03-11 08:20:12 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||907993|
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: https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1088150
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
http://commits.kde.org/kde-workspace/1d08f4779a26ebba757111fd99182034e5282624 "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