[i965] Wierd backlight brightness behaviour looks like flashes on Amilo Si 2636

This is possibly due to some application repeatedly probing the monitor for information. Could you take a look at bug 339200 and bug 344554 and see if you see similarities? Especially, does Xorg.0.log get some lines added to it every time the screen goes black?

Bug 339200: it's said here that random items disappear for a couple of seconds. This is not the case with me, nothing disappears, there is only a split second "dark black flash" and everything resumes normally.

Bug 344554: I saw that one and also Bug 354356, but they are talking about unplugging and hovering with the mouse over the brightness applet. In my case, the flashes seem to be random. One thing I noticed is that they occur frequently after 1-2 min mouse inactivity (but screensaver not yet on, otherwise a dark flash would probably not be visible).

PS: I meant, 1-2 min mouse inactivity, then I move the mouse for the first time after that and I get the flash at exactly that time I start moving the mouse.

Bernhard, do the flashes add anything to Xorg.0.log? You can check by running `while true; do wc -l /var/log/Xorg.0.log; sleep 1; done` in a terminal (stop it with Ctrl+C). This would print the number of lines currently in the file once a second. If the number jumps when a flash occurs, this tells us that it is related to monitor probing. If not, it is something else. Running `xrandr` in another terminal while the above loop is running should also bump the number (and may also cause a flash).

I tried the script and xrandr indeed increases the number of lines of Xorg.0.log, but xrandr never caused any flashes. I couldn't yet figure out if my random flashes change Xorg.0.log because they don't appear that often, I'll look out for that.

But I found something else that is interesting: say I play around with the keys for "brightness up" and "brightness down". Say I go "up" til max brightness and press again "brightness up", then the brightness actually goes down again! And there are some flashes there as well. In other words, if brightness is at max and I press "up" again, then there is definitely a malfunction (it should stay max and not go down). With all these brightness changes, the Xorg file remains unchanged though.

There is actually a quick dark flash whenever I change brightness. It's similar to the other flashes but I cannot tell 100% if it's really the same problem.

Interesting that the flashes appear after inactivity because it could be related to the screensaver. As far as I know it starts dimming the screen slowly and not all at once.

could you not run gnome-panel and see if that's still an issue? it's doubtfully a gnome-panel bug

@Sebastien: actually, I don't know how to run gnome without a panel. :) It's probably not a gnome-panel bug, it's a problem with changing screen brightness. So that means it's an xorg bug?

@Geir: I tried a little more and I can now confirm that a random flash (with me doing nothing on keyboard mouse etc.) does not change the file /var/log/Xorg.0.log. As I said in the updated description, my current conjecture would be that it is related to brightness changes of the screen.

you can try logging a non GNOME session, anyway as said that's probably not a gnome-panel issue closing this task now

Good to know that it does not add anything to Xorg.0.log. That means we can exclude something calling xrandr as being the source of this bug.

I'm not exactly sure where it belongs, but I guess probably the kernel. Screen brightness change goes through the ACPI interface and those bugs are filed to the kernel. In Xrandr.txt (output of `xrandr --verbose`) you have the following lines:
 BACKLIGHT_CONTROL: kernel
  supported: native legacy combination kernel
 BACKLIGHT: 0 (0x00000000) range: (0,7)
which bacally says that the kernel has control of the backlight and that it currently is at level 0 of 7. Could you verify that the first 0 on the last line changes when you turn the brightness up and down? And check what happens to this number when you go beyond the top.

Another place to check the brightness level is in the /proc file system. On my computer /proc/acpi/video/VID/LCD0/brightness has information about the brightness level. You may want to check how this changes when you change the brightness level and you trigger the bug.

Also, does the same happen when you use the hotkeys (Fn+something) to change the brightness level? (assuming that it works).

Yes, there is no difference between the hotkeys and the brightness applet. That's why I thought it's probly not a gnome-panel issue. OK, here's the experiment, start out with dark screen (lowest brightness) and I keep going up in brightness:

BACKLIGHT: 1 (0x00000001) range: (0,7)
now go up by one hotkey
BACKLIGHT: 4 (0x00000004) range: (0,7)
go up by one hotkey
BACKLIGHT: 5 (0x00000005) range: (0,7)
go up by one hotkey
BACKLIGHT: 6 (0x00000006) range: (0,7)
go up by one hotkey
BACKLIGHT: 7 (0x00000007) range: (0,7)
go up by one hotkey
BACKLIGHT: 0 (0x00000000) range: (0,7)
max! now go up once more
BACKLIGHT: 7 (0x00000007) range: (0,7)
go up again
BACKLIGHT: 2 (0x00000002) range: (0,7)
goes down to 2! go up again
BACKLIGHT: 0 (0x00000000) range: (0,7)
back to max! now go up again
BACKLIGHT: 0 (0x00000000) range: (0,7)
and stays there...
BACKLIGHT: 0 (0x00000000) range: (0,7)
even if I keep going up, now it's always
BACKLIGHT: 0 (0x00000000) range: (0,7)

Note that this problem only occurs if I am at the min and go up to max then it bounces back to 2 and only then stays at the top. There is no such malfunction if I'm at the top and go to the min. I have a strong feeling that this behavior is related to the flashes.

Strange... Does the same happen with /proc/acpi/video/VID/LCD0/brightness? (it goes up to max, drops down, etc.)

Also, 0 should not be minimum, not maximum... On my computer it is
 BACKLIGHT: 12 (0x0000000c) range: (0,15)
and the value goes from 0 (minimum) to 15 (maximum)

It's clearly the max for me when Backlight is on 0, don't know. You don't have this bouncing behavior? Maybe it's the intel video card.
As for the brightness file, I can't find it, is it a text file?

> locate brightness
/etc/acpi/video_brightnessdown.sh
/etc/acpi/video_brightnessup.sh
/etc/acpi/events/asus-brightness-down
/etc/acpi/events/asus-brightness-up
/etc/acpi/events/panasonic-brightness-down
/etc/acpi/events/panasonic-brightness-up
/etc/acpi/events/video_brightnessdown
/etc/acpi/events/video_brightnessup
/etc/acpi/resume.d/50-tosh-restore-brightness.sh
/etc/acpi/suspend.d/50-tosh-save-brightness.sh
/etc/laptop-mode/conf.d/lcd-brightness.conf
/usr/lib/gegl-0.0/brightness-contrast.so
/usr/lib/gnome-power-manager/gnome-brightness-applet
/usr/lib/hal/scripts/hal-system-lcd-get-brightness
/usr/lib/hal/scripts/hal-system-lcd-set-brightness
/usr/lib/hal/scripts/linux/hal-system-lcd-get-brightness-linux
/usr/lib/hal/scripts/linux/hal-system-lcd-set-brightness-linux

and some brightness icons.....

You might think that if it's at the max (in my case 0) and you press the hotkey "up" then it would always behave in the same way. But it doesn't: if it comes from 1-4-5-6-7-0 it bounces but not if it comes from 7-2-0. There must be some hidden variable. :)

For sure you have a /proc/acpi directory. Do you have a video directory in there? If so, do you have a VID directory in there? If so, a LCD0 directory in there? If so, what files do you have there? Nothing under /proc are real files, it's a filesystem the kernel uses to inform/communicate with users and programs. Most of the so-called files there are text files, and you can read them with `cat filename`. In my case:
$ cat /proc/acpi/video/VID/LCD0/brightness
levels: 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 100
current: 75

I don't think the bug is in the intel driver. It is likely a ACPI bug that belongs in the kernel. Take a look at https://wiki.ubuntu.com/DebuggingACPI and upload the information they ask for. We'll assign the bug to the kernel after that.

OK, I found "brightness", it doesn't list under locate. Here's the funny output:

> xrandr --prop
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 286mm x 179mm
 EDID_DATA:
  00ffffffffffff0030ae314000000000
  00110103801d12780a2f309758538b29
  25505400000001010101010101010101
  010101010101bc1b00a0502017303020
  36001eb3100000180000000000000000
  000000000000000000000000000f0081
  0a32810a28190100320c00f5000000fe
  004c503133335758312d544c43310078
 PANEL_FITTING: full_aspect
  supported: center full_aspect full
 BACKLIGHT_CONTROL: kernel
  supported: native legacy combination kernel
 BACKLIGHT: 0 (0x00000000) range: (0,7)
   1280x800 59.9*+
   1024x768 85.0 75.0 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 72.8 75.0 59.9
   720x400 85.0
   640x400 85.1
   640x350 85.1
TMDS-1 disconnected (normal left inverted right x axis y axis)
> ls /proc/acpi/video/GFX0
DD01 DD02 DD03 DD04 DD05 DOS info POST POST_info ROM
> cat /proc/acpi/video/GFX0/DD01/brightness
<not supported>
> cat /proc/acpi/video/GFX0/DD02/brightness
levels: 0 1 2 3 4 5 6 7
current: 7
> cat /proc/acpi/video/GFX0/DD03/brightness
levels: 0 1 2 3 4 5 6 7
current: 1
> cat /proc/acpi/video/GFX0/DD04/brightness
<not supported>
> cat /proc/acpi/video/GFX0/DD05/brightness
<not supported>

So when I have max brightness, xrandr says I have brightness "0", in DD02 it's "7" and in DD03 it's "1". Have no idea why. I'll look into the acpi bug filing later, should I attach everything here or should we file a new bug?

Also tried some of the other brightness levels, the numbers never cohere or maybe I'm just missing the pattern.

OK, I attached whatever they wanted. I will try to update the bug description to give it in a nutshell since there is a lot of red herrings in the thread.

Thanks for uploading all the ACPI related information. I have opened this bug for linux and closed it for xorg and xserver-xorg-video-intel (FYI: xorg is just a meta-package for people who don't know which xorg-related package to put a bug into, and as such really makes no sense together with xserver-xorg-video-intel).

This problem still persists with Kernel 2.6.28.11-generic. Could we get some feedback from the kernel people to confirm if it's really a kernel bug?

Apparently, there are many ways to control the backlight, and while using the kernel is the default on your hardware, it is possible to change that with xrandr. Take a look at bug 367309 for how to do this. Could you check if you have the same weird behavior with the other settings?

I updated xorg-xserver-video-intel to 2.7 today and haven't had any flashes since (still testing though). But the strange brightness hierarchy (see description on top) remains. I wonder if bug 367309 is a duplicate of this one.

Actually, hard to tell if it's a duplicate or not. The reporter of bug 367309 talks about a range 0-296 and if I type "xrandr --prop", then I only have the range 0-7.

The bugs are similar, but I'm not sure they are duplicate since it seems to be on different hardware and the default backlight control is different. I have tagged both bugs with the "backlight" tag, though, so if a solution comes up for one, the other bugs with that tag can be checked.

Unfortunately I was wrong, I still get these flashes even with xserver-xorg-video-intel 2.7. They seemed to get better but today they are back. Even with metacity window manager.

Yesterday I even installed the 2.26.30 kernel for a while but I couldn't adjust any brightness settings in that one (hence no flashes).

I used Aldrin's advice from bug 367309 and that actually fixes my problem with the bizarre brightness settings (I have yet to long-term-test if the flashes go away as well). You type

xrandr --output LVDS --set BACKLIGHT_CONTROL combination

and the brightness behavior is completely normal again. How can I have this permanently set (instead of running a script everytime I login)? Maybe it could be fixed since many people have this intel video card. Shouldn't it be fixed in xserver-xorg-video-intel?

> Maybe it could be fixed since many people have this intel video card.
> Shouldn't it be fixed in xserver-xorg-video-intel?

I don't think everyone with the same video card has this problem, it's
probably specific to the Amilo or even your particular model. I have
the same video chipset as you have (except I have "(rev0c)" instead of
"(rev03)" in the output of `lspci -vvnn`) and I don't have this
problem. My guess is that it is a problem in how the kernel interfaces
with your particular hardware.

I don't know whereis the best place to change the backlight control
setting permanently. Possibly, in ~/.config/monitors.xml if you have
one, but maybe this is not possible.

I filed a new bug which could be related to this issue.
Bug #370773.

I can confirm the same behavious as Bernhard, in that I suffer the random backlight flashes when moving the cursor following a period of inactivity, and running

xrandr --output LVDS --set BACKLIGHT_CONTROL combination

corrects the problem.

Here are the first lines of lspci:
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)

Please ask me for whatever additional information may be required and I'll provide it.

[This is an automatic notification.]

A new major version of the -intel driver is now available in Karmic.

This version includes a major reworking of the acceleration
architecture, which resolves a huge number of issues. We do not know
whether it resolves the issue you reported.

Would you mind testing Karmic Alpha-2 and seeing if it is still a
problem? CD ISO images are available here:

  http://cdimages.ubuntu.com/releases/karmic/

If the issue can still be reproduced on karmic, please report here with
your findings, and attach a fresh Xorg.0.log from your test, and we will
be able to forward the bug upstream.

Otherwise, if the bug no longer exists in Karmic, let us know that as
well.

In the off chance you encounter different bugs while attempting to test
Karmic, please report those as new bug reports.

I just played around a little with the 2.6.30 kernels from the jaunty repo (thx for putting them in!) and this particular problem seems to be fixed there.

Bernhard, thanks for testing and the feedback. Just fy, the upcoming kernel for the Karmic release will actually target the 2.6.31 kernel. Since the 2.6.30 kernel sounds promising to fix this issue, I wouldn't expect this issue to regress when the kernel is bumped to 2.6.31. The 2.6.30 based kernels are already available for testing in the Karmic Alpha releases, so for now I'm marking the "linux (Ubuntu)" task as Fix Released. However, if you do notice the issue return when using these newer kernels, please feel free to reopen this bug (ie set the Status from Fix Released back to New). Thanks.

Thanks for letting us know the issue is resolved.