Archived thread 1035010 from System76 Support. Markdown source: System76_Support/thread_1035010_"LCD_brightness"_stopped_working_System7.md
This morning I performed the following relevant updates:
The GNOME Power Manager Brightness Applet now shows a red circle-and-slash, with flyover text of "Cannot get laptop panel brightness". Additionally, the Fn+F8 and Fn+F9 keys no longer adjust the backlight.
What should I do to regain this functionality? Are there any logs you want to see?
Hi, Phyzome.
That is a proposed kernel, which, of course, is supposed to provide fixes but isn't fully tested yet.
Chances are these problems will fix themselves as the kernel works its way towards being officially released.
Of course, that estimation of the problem is assuming that the functionality you mentioned is still present in previous kernels. Is it?
thomasaaron said: That is a proposed kernel, which, of course, is supposed to provide fixes but isn't fully tested yet.
Chances are these problems will fix themselves as the kernel works its way towards being officially released.
*sigh*
How long have I been running with Proposed selected? That could explain a lot of problems...
I'll do a backup and see what I can safely downgrade to supported versions.
Yep, same problem for me. I 've just reported a bug here:
https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/315596
I backed the kernel (and other packages) down out of Proposed. Here is what has happened as a result:
Do...
sudo apt-get --reinstall install linux-backports-modules-intrepid
...and that should stop the freezes. If not, try re-enabling backports in your software sources and running updates. I don't think it's the backports that caused your problems. I think it was the proposed kernel.
So I installed the new recommended kernel update to 2.6.27-11 and it fixed not being able to change to screen brightness. Although it is buggy.
When using the applet pushing + or - makes the brightness change slow, too slow. Upon going all the way down the screen the applet gets the red slash like it should, but when you go back up the red slash stays there until you either log out then back in, or remove then add the applet.
Another thing is when you click on the applet a second time the scroll bar is not directly under the white applet but far off the the left. Never off screen.
When using the hot keys the screen is slow to respond to the command and takes too large off leaps instead of too little.
Anyone else get these?
System: Panp4n Ubuntu 8.10 64bit Kernel 2.6.27-11
thomasaaron said: Do...
sudo apt-get --reinstall install linux-backports-modules-intrepid
...and that should stop the freezes. If not, try re-enabling backports in your software sources and running updates. I don't think it's the backports that caused your problems. I think it was the proposed kernel.
Nope, it happened again. When it happens, I can't even shut down normally. Here are various symptoms:
Ultimately, I have to use [Alt/Gr]+[SysRq]+[r,e,i,s,u,b] to restart.
This usually occurs upon resume after the laptop has been suspended for a long period of time, such as overnight.
Attached are some interesting bits (maybe even relevent!) retrieved from kern.log.
I don't see anything in the logs that really helps me understand this. If it's never shutting all the way down, there is a seriously hosed script/configuration/something somewhere.
I'm guessing that backing out of the -11 kernel left something behind.
As far as the suspend not resuming intermittently after long suspends, that may be a bug. I can try to test that here.
thomasaaron said: If it's never shutting all the way down, there is a seriously hosed script/configuration/something somewhere.
No, it *usually* shuts down just fine. The hang-on-shutdown only occurs with this post-resume nonsense.
thomasaaron said: I'm guessing that backing out of the -11 kernel left something behind.
This was happening before I ever messed with Proposed, I'm sure of it.
thomasaaron said: As far as the suspend not resuming intermittently after long suspends, that may be a bug. I can try to test that here.
To clarify: The laptop does resume, but something (probably at the level of kernel module) gets broken in the process of either suspending or resuming.
It also may have something to do with Network Manager.
Thanks. I understand better now. I've actually had that happen to me before. However, I never suspend for *really* long periods of time.
Probably filing a bug report is the best way to go on this one, as a) it's going to be kind of figure out, b) it should probably be checked out on a number of our systems.
About how long do you think we have to keep it in suspend to duplicate the problem?
thomasaaron said: About how long do you think we have to keep it in suspend to duplicate the problem?
Not sure. I usually suspend mine around midnight and resume it at 8:00 AM.
I don't know *why* the length of time would matter, but it *seems* to.
At one point, I noticed that if I disabled software wireless and then the hardware radio before suspending, the problem occurred *much* less frequently.
Next time this happens, what logs should I retrieve?
messages syslog daemon.log