Screen brightness does not revert after opening screen
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Screen brightness does not revert after opening screen
I just installed the newest set of updates, so I am running Slackware Current. My hardware is a Panasonic CF-29 Toughbook.
Since the update, closing the screen while X is running has caused the screen to become irreversibly dark. The virtual console where X was running is completely black. The ttys are just barely readable. I'm able to use them to shut down the computer.
Does anyone know what's causing this or what could be causing this?
EDIT: The keyboard brightness controls do not work when I open the monitor. After restarting the computer, they do work again. When lilo loads, the brightness is at minimum. During lilo, I can use <Fn> + <F2> to increase the brightness to a reasonable level.
Just out of curiosity, when that next happens, if you then ctrl-alt-backspace to forcibly exit x-windows and return to the console, is the screen then visible?
Edit: I expect your screen will remain dark, but you never know.
No, in fact, ctr-alt-backspace works properly. Except the console's brightness is now set to minimum. Apparently the Fn+[F1/F2] doesn't work in the console, so I have to reopen X to fix the brightness.
I understand this is a difficult problem to diagnose. I already sold this computer, and I would feel like a much better person if I could fix this problem within the next 24 hours.
I also have noticed some oddities with my backlight recently (also i915). But it wasn't such a bother that I'd actually take action. After suspending, the backlight will be at the lowest state. If I press a button however or move the mouse, it will recover. This rather new but I don't remember where it started.
In your case, I'd try some i915 kernel parameters (see modinfo i915) and check dmesg/Xorg.0.log. Furthermore I'd inspect /sys/class/backlight/ to see if the actual brightness is recognized by the drivers and/or can be set there.
Is the backlight actually off or just set to lowest power?
Does the problem also occour when X is not involved (e.g. suspending in console in runlevel 3).
I've also been having trouble with the backlight staying dark after resume, also on i915 hardware (2008 black MacBook4,1). I'm upgrading right now to try the latest -current, but I can tell you that for me the problem first appeared with the 3.18.11 kernel that appeared in -current a while ago, so I've just been running the 3.14.18 kernel that was the last version to work for me. I have also tried 4.0.6 and 4.1.3 kernels that did not work.
One thing that I've noticed, is that with the 3.14.18 kernel, I see messages like this in /var/log/messages:
Oct 28 20:33:12 shams kernel: [69910.541117] video LNXVIDEO:00: Restoring backlight state
but I don't see those messages with the 3.18.11 and later kernels.
As soon as I'm booted into the 4.1.12 kernel, I'll give you an update.
Sorry for the delay, the upgrades caused some (third party) breakage that I needed to fix.
When I run the -current kernel-generic-smp-4.1.12_smp-i686-1 kernel, my backlight also fails to re-light on resume.
Answering eldercitizen's questions: the backlight does appear to be completely off, the problem happens without X (suspend from console), and none of the following work:
xbacklight -set 100
xset dpms force off ; xset dpms force on
echo 12 >/sys/class/backlight/apple_backlight/brightness
echo 100 >/sys/class/backlight/apple_backlight/bl_power
I've also tried adding both 'video.use_native_backlight=1' and 'video.use_native_backlight=0' to the kernel command line (different boots, of course), and neither seem to have any effect. I tried this after noticing that under the 3.14.18 kernel, I have these two directories:
Probably false-alarm from my side. I had a "xset dpms force off" in my standby-script right before going standby. I just noticed this because with the 4.3.0 kernel it stayed dark after standby (whereas it was only dim with older kernels). Disabling the command solved my problems for the current kernel as well as for the older ones.
fiddlesean: Do you have acpi_video loaded? This is what normally gives off the "LNXVIDEO:00: Restoring backlight state" message.
Any mentioning of i915 in the dmesg (because intel-backlight)?
What kind of suspend are you using? (I simply "echo mem > /sys/power/state")
> Do you have acpi_video loaded? This is what normally gives off the "LNXVIDEO:00: Restoring backlight state" message.
Code:
$ lsmod | grep video
video 11067 1 i915
thermal_sys 22729 2 video,processor
> Any mentioning of i915 in the dmesg (because intel-backlight)?
Code:
$ sudo dmesg | grep i915
[ 13.207662] [drm] Initialized i915 1.6.0 20150327 for 0000:00:02.0 on minor 0
[ 14.026459] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 14.026505] i915 0000:00:02.0: registered panic notifier
[ 16.292082] [drm] GMBUS [i915 gmbus dpc] timed out, falling back to bit banging on pin 4
[ 16.356057] [drm] GMBUS [i915 gmbus dpd] timed out, falling back to bit banging on pin 6
> What kind of suspend are you using? (I simply "echo mem > /sys/power/state")
pm-suspend from /etc/acpi/acpi_handler.sh, triggered by lid close.
> Care to share your dmesg (after suspend)?
Attached (4.1.12-after_suspend.txt). I've also attached the dmesg from my last-known-working kernel (3.14.48-after_suspend.txt) for comparison and an lspci to help interpret device numbers, in case that's useful.
Thanks, eldercitizen. That bug looks similar to mine, but differs in these ways:
- The person filing the bug can get his backlight to switch back on by pressing one of the function keys. I have yet to find any way to get my backlight to come back on, short of rebooting.
- His backlight problem appears to be intermittent, mine always.
What is really interesting is that adding 'acpi_backlight=native' to his boot command line appears to have solved the problem for him (the discussion is unclear). The 'native' option is only available in 4.2 and later kernels, so I think my next step will be to try one of those.
Darn. Running kernel 4.3.0 with 'acpi_backlight=native' on the boot command line does not help. Neither does replacing 'native' with 'vendor', 'video', or 'none'. Same thing, no /sys/class/backlight/intel_backlight, backlight does not light on resume from suspend.
Anybody know how much disk space a kernel git bisect needs?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.