Since latest kernel updates, screen brightness control is working on my Samsung n210 laptop (see bug #703819 and #648872). But since, under X11, the screen brightness start flickering without reason at random moment. At some point, the "Brightness popup/OSD" appears on screen and the screen continue to flicker. Manually adjusting the brightness doesn't stop flickering. Switching to a virtual console and switch back to X11 halt the flickering.
It seems it only flicker on battery when idle. If the computer is doing something, brightness doesn't seems to start flickering. But, if it's doing nothing and I unplug the power cable, then it start to flicker. If I don't plug the power cable back or switch to a virtual console, the computer is likely to freeze and require a manual reset. Note: the problem also happen on Fedora 16 TC.
See also bug #737108. But I don't have any messages in kernel logs.
Is this only happening when you are running on battery? If so, try changing the power management settings for the desktop by unchecking "reduce backlight brightness" and "dim display when idle". Some further things to try: - Add "acpi_backlight=vendor" to the kernel boot options. - If that doesn't work, also add "samsung_backlight.use_sabi=0 samsung_backlight.force=1" to the boot options.
Still not fixed in 2.6.40.7-3.fc15.x86_64. But behavor changed for the first unplug: the backlight is correctly reduced, but not restored when power plug is plugged back. If I increase the backlight level to a higher level (the level set before unplugging the power), then unplug again the power adapter, the screen start to flicker again.
(In reply to comment #3) > Is this only happening when you are running on battery? If so, try changing the > power management settings for the desktop by unchecking "reduce backlight > brightness" and "dim display when idle". > This is a workaround. I'm going to try the other workaround.
I have looked on the patches that were linked from https://bugzilla.redhat.com/show_bug.cgi?id=737108#c2 And I found this one, that might fix my problem https://lkml.org/lkml/2011/5/13/150
Yep, that sounds pretty much like the behaviour that I was getting that led me to write the patch. If you open a terminal while in your DE, adjusting the brightness via the sys interface (at /sys/class/backlight/samsung/brightness ? can't confirm right now) by steps of two or more should you will probably get the same behaviour. Adjusting in single steps should work properly though. The last I know of the patch's progress into mainline is Greg Kroah-Hartman forwarding it on to Mathew Garret: https://lkml.org/lkml/2011/9/20/332 I'm not sure if it's progressed from there or not.
(In reply to comment #7) > The last I know of the patch's progress into mainline is Greg Kroah-Hartman > forwarding it on to Mathew Garret: > https://lkml.org/lkml/2011/9/20/332 > > I'm not sure if it's progressed from there or not. Lets ask him about it.
(In reply to comment #7) > Yep, that sounds pretty much like the behaviour that I was getting that led me > to write the patch. If you open a terminal while in your DE, adjusting the > brightness via the sys interface (at /sys/class/backlight/samsung/brightness ? > can't confirm right now) by steps of two or more should you will probably get > the same behaviour. Adjusting in single steps should work properly though. > I'm able to trigger the flickering problem sometimes using such sequence: for i in 0 2 4 6 8 7 5 3 1; do echo -n "$i "; echo $i > /sys/class/backlight/samsung/brightness ; cat /sys/class/backlight/samsung/brightness ; done But some other times the screen doesn't flicker, but the brightness level is not correct: here the output: 0 0 2 2 4 4 6 4 8 5 7 6 5 5 3 3 1 1
Changing the sequence to this one (inverted echo position): for i in 0 2 4 6 8 7 5 3 1; do echo $i > /sys/class/backlight/samsung/brightness ; echo -n "$i " ; cat /sys/class/backlight/samsung/brightness ; done Give more chance of screen flickering. Results are funny too. 0 0 2 2 4 4 6 6 8 8 7 6 5 5 3 7 1 1 While the screen is flickering, the graphical environment (gnome-shell) is becoming unusable. I have to switch to a virtual console and get back to stop the screen to flicker. Could this be a problem the on-screen-display (gnome-shell/gnome-settings), that can't cope with the increase rate of brightness changes ?
When I was first tracking down the problem, I looked into how KDE's powerdevil works and initially thought it was a problem there too. Gnome shell probably works in a similar way. What is happening though is that, when the current brightness is 3 and something attempts to set it to 5 or higher, the actual brightness becomes 4 and a KEY_BRIGHTNESS_UP event is generated. Actually, the brightness key event is generated even on single increments. Powerdevil would then react to the key event, creating a sort of loop. Throw the fact that powerdevil does brightness animations, only deals in percentages and that there can be a delay in the processing of brightness key events, it becomes very easy for the system to get into a sort of brightness up/down loop. But the real problem is that a brightness key event at all and that is what my patch fixes.
By the way, there's also been a patch submitted to my patch. My patch fails to detect the problem and switch on the workaround if the initial brightness is 0. I didn't think that would be a problem in the real world, but apparently it is: https://lkml.org/lkml/2011/10/13/143
from bug 737108 comment 6 > Package kernel-2.6.40.8-2.fc15 > * should fix your issue, It doesn't fix flickering problem for this bug.
(In reply to comment #7) > I'm not sure if it's progressed from there or not. My apologies. I should have checked before writing this comment, but everything is in linux-next now: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=drivers/platform/x86/samsung-laptop.c;h=09e26bfd464343766a3bfcff39d4b6e0a306f179;hb=HEAD
(In reply to comment #14) > (In reply to comment #7) > > I'm not sure if it's progressed from there or not. > > My apologies. I should have checked before writing this comment, but everything > is in linux-next now: > > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=drivers/platform/x86/samsung-laptop.c;h=09e26bfd464343766a3bfcff39d4b6e0a306f179;hb=HEAD Those commits are in the latest rawhide kernel now. Would someone be willing to install that kernel and test for this issue?
This is fixed in Fedora 15, kernel-2.6.41.1-1.fc15.x86_64 https://admin.fedoraproject.org/updates/kernel-2.6.41.1-1.fc15 * Fri Nov 11 2011 Josh Boyer <jwboyer> 2.6.41.1-1 - Linux 3.1.1 * Fri Nov 11 2011 John W. Linville <linville> - Remove overlap between bcma/b43 and brcmsmac and reenable bcm4331 * Thu Nov 10 2011 Chuck Ebbert <cebbert> - Sync samsung-laptop driver with what's in 3.2 (rhbz 747560) See also bug 737108
Thank you for letting us know.