https://bugzilla.kernel.org/show_bug.cgi?id=25072
--- Comment #7 from Indan <[email protected]> 2011-02-09 10:53:02 --- If it does nothing it probably just blanks the screen. Is getting 8 levels instead of 16 something introduced by my remove_is_backlight_combination_mode patch? And is that 8 effective levels of brightness, or 8 detected levels of brightness? Give fix_combination_mode.diff a try instead. I hope it won't help, because it's quite ugly. But I fear it does. The output of "dmesg | grep backlight" with drm.debug=0x2 would be interesting if this patch helps. The thing is, the old code did weird things when it detected combined mode, so it doesn't surprise me that the backlight levels are different. Question is, are they right now? Is the lowest level dark enough and the highest bright enough? Furthermore, if your laptop remembers the brightness between reboots, then old, incorrect values may be restored as well, and the patched kernel won't fiddle with messed registers. So set the brightness at the maximum in the vanilla kernel before rebooting into a patched one. So before you do anything, go into the broken kernel, set brightness to maximum, reboot into the patched one and see if everything is all right. (Or set brightness to max in the BIOS if possible.) If not, try the above mentioned patch. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
