Ubuntu launchpad entry: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/446717 Summary: When Appearance -> Visual Effects are set to "none" brighness keys act as expected with small screen glitches at the bottom of the panel. With Appearance -> Visual Effects set to either "Normal" or "Advanced" changing brightness via the keys causes system to become unresponsive. Mouse does not move, keyboard does not work EXCEPT the ability to continue changing the brightness. Only way out is hard power off (or restart via sysreq). I have attempted to enable visual effects and disable all plugins via CCSM with no luck. Confirmed to be happening in Ubuntu karmic, lucid and also maverick. I have this same problem on my Acer Aspire 5810t.
Versions: libdrm-intel1 2.4.18-1ubuntu3 xserver-xorg-video-intel 2:2.9.1-3ubuntu5 There are some stack traces over at Launchpad. If you need more traces or other debug information, just tell me. I can reproduce the bug (and do so more often than I like :-)).
Versions for my setup: OS: Linux Distribution: Ubtuntu Maverick Meerkat Kernel: Linux shaitan 2.6.35-19-generic #28-Ubuntu SMP Sun Aug 29 06:34:38 UTC 2010 x86_64 GNU/Linux Relevant versions: libdrm-intel1 2.4.21-1ubuntu2 xserver-xorg-video-intel 2:2.12.0-1ubuntu3 If there is any more you wish to know, just ask.
From the superficial information in the bug report, it looks like a page-flipping hang. http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=drm-testing&id=8a0f4c6aa8de504e9b4ffef08dc8a7c7cf9b07a1 should help.
I compiled the kernel from that repository (commits 3656738f06dabc33d5800f66882f4671f592b402 and a67987cb6fae464b6837f3351d1fcdb38f82e598). The bug seems to be gone (i.e. no freeze), BUT the backlight is completely switched off on start up and does NOT change when pressing the corresponding keys (Ubuntu still shows the bubble that notifies the user of the changed backlight level). Furthermore my own fix, a little script, that sets the brightness directly using setpci, does not work anymore. The /sys/class/backlight/acpi_videoX/brightness as well as /proc/acpi/video/VGA/LCD/brightness files are present and reflect the changes of the brightness (when I do "echo X > ..." the actual_brightness file changes, when press the brightness keys, the content of the files changes).
The bug is fixed for me by the following commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4e5359cd053bfb7d8dabe4a63624a5726848ffbc It is part of kernels >= 2.6.36-rc4. Setting the brightness for me still is somehow weird (after pressing Fn+left_arrow more than one time, Fn+right_arrow switches the brightness down instead of up one time, it has just got 5-6 levels, while the /sys and /proc filesystems suggest 10 levels (on 2.6.36-rc5)), but it is a great thing to be able to press buttons without the constant fear of a freeze.
I'm testing kernel 2.6.36-rc5 on OpenSuse 11.3 and the bug seems gone for me too, thanks everyone! After two days of heavy usage I only got a total freeze which seems unrelated to backlight adjustments, and differently from before it also affected the mouse pointer. Accuracy is quite bad, exactly as Martin says, plus the OSD is responding badly, but this isn't perfect in Windows either. I think that behavior is Acer's fault (bios maybe), but perhaps would need another bug report in future.
There is a script proposed for setting the backlight using setpci: https://help.ubuntu.com/community/AspireTimeline/Fixes I'm using a modified version and I can set the backlight quite accurately.
@ Martin: thank you, but I was already using that script while in Fedora. In OpenSusue though, I wasn't able to make it work due to setpci requiring root permissions, and subsequent complications. And I couldn't change the "Fn" hotkeys, risking freeze anyway when I unintentionally pressed them.
I can confirm that brightness changes work with kernel 2.6.36-rc. However, the computer becomes very slow after changing brightness. I haven't got a clue why, so my current solution is rebooting... This makes the ability to change brightness rather useless. Btw, I'm using Ubuntu 10.04.1 on an Acer 4810T.
Mass status change to NEEDINFO based on presence of NEEDINFO keyword. Please reopen if you can still reproduce the bug and are able to provide the information requested, thanks.
I have a 4810T with Ubuntu 12.04, and can still reproduce the bug. Please tell me what information you need.
Since there is no direct connection between compiz and the backlight, the description that "compiz freezes when changing the backlight" makes no sense. First step would be to reproduce with an uptodate stack and then attach dmesg, Xorg.0.log and /sys/kernel/debug/dri/0/i915_error_state. Hopefully that will give enough clues as to where to look next.
Created attachment 60463 [details] dmesg
Created attachment 60464 [details] i915_error_state
Created attachment 60465 [details] Xorg.0.log
Dammit, you're fast :) Hope this is the information you required? From what I can tell, there are no signs of error in dmesg and i915_error_state, but the last line in Xorg.0.log might indicate something suspicious.
Yeah, that last line I was going to ask about. Are you aware of changing VT 5 minutes after booting? Otherwise there are no warnings nor errors aside from that your BIOS is full of holes. Do you have a second laptop? Can we log into the machine whilst frozen to inspect process state? One thing, though it might be a bit tricky to arrange, is an xtrace of compiz. The obvious was would be to start X, start xtrace, then DISPLAY=:9 compiz [or rather your normal session]. Have you tried forcing a VT switch? Forcing a mode switch? Hot-plugging?
Firstly, I did not realize what a VT switch was until right now (didn't know the term) and yes, I did one right after the computer froze. I also just realized that no one has reported that while the graphics freezes, it is still possible to hit Ctrl+Alt+F[1-6] to get to a different VT. It is thus no problem to extract information while in the frozen state. I'm not sure I understand exactly what you want me to do, but I'll try to run xtrace while reproducing the error?
Created attachment 60466 [details] xtrace output
I'm not entirely sure what I just did, but I tried to reproduce the error while running xtrace. I started xtrace -k -D:9 -d:0 -o xtrace.log from a VT, and then ran export DISPLAY=:9; unity --replace from another (I couldn't run compiz alone, it just gave me an error msg). Then I went back to X and changed brightness, which caused the graphics to freeze as usual. I don't know if that is what you wanted me to do, I couldn't see anything interesting in the xtrace.log file. But then again, I'm not the expert.
Yes, it tells me that compiz stops rendering - it is notified of the fullscreen damage and does not redraw the screen.. The ball is in their court.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.