Also, there should only be 8 brightness levels.

would you please attach:

1)lspci -vvxxx
2)acpidump
3)dmesg

thanks.

Created attachment 14177 [details]
lspci output

Created attachment 14178 [details]
dmesg output

acpidump will have to wait as this package is not present in Fedora Package Collection.

we still need the acpidump info to confirm. thanks.

Created attachment 14188 [details]
ACPI tables dump

I obtained this one using Linux Firmware Kit R3. Please let me know if it is the file you required.

Hmm, please set CONFIG_ACPI_DEBUG and
kill acpid
"cat /proc/acpi/event"
"echo 0x8800001f > /sys/module/acpi/parameters/debug_level"
"echo 0x04 > /sys/module/acpi/parameters/debug_layer"
and press the hotkey Fn-F6 and Fn-F7 one time for each
and attach the dmesg output and the result of /proc/acpi/event.

Created attachment 14260 [details]
dmesg output with ACPI debugging enabled

[root@snowball ~]# cat /proc/acpi/event
video LCD 00000087 00000000
video LCD 00000087 00000000
video LCD 00000086 00000000
video LCD 00000086 00000000

I also had to stop haldaemon, since it was blocking the access to /proc/acpi/event. The logs were obtained using 2.6.23.9-85.fc8debug kernel.

Also, looks like stopping haldaemon resolved the gnome-power-manager issues, mentioned in bug #9262 and #9277.

Method (_Q60, 0, NotSerialized)
{
...
If (LEqual (Local0, 0x41))
   {
   Notify (^^^GFX0.LCD, 0x86)
   Notify (^^^PEGP.VGA.LCD, 0x86)
   }
...
}
and 
Method (_Q64, 0, NotSerialized)
     {
     Notify (^^^GFX0.LCD, 0x86)
     Notify (^^^PEGP.VGA.LCD, 0x86)
     }
Yes, by checking the DSDT table you attached, BIOS sends two notifications for one key press each time.
ACPI can never know which video bus actually works. It just executes the BIOS code and exports the notifications to user space. And unfortunately, the two LCD devices have the same name in this laptop, thus user space changes the brightness level twice in a row...

We met the duplicate video device problems before, but there is still not a fix for this. :(.
For your box, you probably need to fix it in userspace for now. ie, modify the script to change one brightness level per two acpi events.

Thank you for the feedback. If such problem is common, maybe it would be worth to create a hal quirk doing that? There is one (laptop_panel.brightness_in_hardware), but I am not sure if it is supposed to fix the issue we have here. I'll try it out.

I have a quick look at laptop_panel.brightness_in_hardware, I'm afraid it can't fix your problem at hand.

I think we really need to get a proposal on how to fix it in kernel.
Duplicate video bus device shown in ACPI namespace, one stands for the integraded VGA controller, while another stands for an external graphics card.
There was a patch sent by thomas for fixing this problem, you may have a try.
http://marc.info/?l=linux-acpi&m=119703212318089&w=2

The patch from comment #13 fixes the issue for me. Without haldaemon and g-p-m running, I can switch through 8 values of brightness, as under windows. There is only one device visible as well.
If haldaemon and g-p-m are running, one issue remains. There are nine steps down (the last one does not really do anything) and eight steps up. I suspect that's because the percentage values do not overlap with eight available levels very well. I'll try laptop_panel.brightness_in_hardware quirk and report back.

The quirk does not change anything here. Looks like a bug in gnome-power-manager then - the two lowest values are reported by /proc/acpi/video/VGA/LCD/brightness as 10.

Rui, can you point Len's attention to this one, pls.
I posted this on acpi list twice. Matthew Garrett had some concerns that some graphics devices could get rejected wrongly, but this has to be proven by a real machine/DSDT first (and can then get fixed up more fine grained if necessary).
IMO my patch should be added, I thought it already had.

Created attachment 14529 [details]
patch-ignore-acpi-video-devices

can you please try this patch and make sure it works for you?

(In reply to comment #17)
> Created an attachment (id=14529) [details]
> patch-ignore-acpi-video-devices
> 
> can you please try this patch and make sure it works for you?

Works fine for me. With it, I only have one video bus left. Consequently, brightness control works as it should. This is on a Toshiba Satellite Pro A100-080.

Works for me as well. There is only one video device left (/proc/acpi/video/VGA, as opposed to /proc/acpi/video/VGA and /proc/acpi/video/GFX-0 before), and along with the patch from bug #9277, brightness controls work like charm.

FYI, this laptop was sold as “Designed for Windows XP, Windows Vista Capable”. I did update the BIOS several times since I bought it, though.

applied patch in comment #17 to acpi test branch

a cleaned up version of Matthew's patch in comment #17
shipped in linux-2.6.24-rc22
closed

looks like i messed up.

0119509c4fbc9adcef1472817fda295334612976
ACPI: video: Ignore devices that aren't present in hardware

indeed went upstream between 2.6.24 and 2.6.25-rc1 --
but it shouldn't have because it wasn't the final patch.

A later version of that patch also went upstream 
between 2.6.24 and 2.6.25-rc1

3fa2cdcc45a0176de15cac9dbf4ed2834ebf8932
ACPI: video: Ignore ACPI video devices that aren't present in hardware

The two patches have the same function, but the text doesn't collide,
so I didn't notice the merge error.

commit 0119509c4fbc9adcef1472817fda295334612976 was reverted in Linus' tree

Due to regression bug 9995, these patches were reverted
between 2.6.25-rc6 and 2.6.25-rc6-git8 in the following commits:

0d6752c9fa51d24c86b57c76ec5b2926a716b23
Revert "ACPI: video: Ignore ACPI video devices that aren't present in hardware"
77321e624b64f1e5985a20f3cd16b94c96d0dbb4
Revert "ACPI: video: Ignore devices that aren't present in hardware"

so this sighting is REOPENED.

I have a thinkpad T61 with the same kind of bugs.

Using 2.6.25.1, I have two acpi_video* in /sys/class/backlight.

Brightness keys manage to change both acpi_videoX/actual_brightness, but acpi_videoX/brightness doesn't change.

echo XX > acpi_video1/brightness changes acpi_video1/brightness and acpi_video1/actual_brightness _and_ the effective LCD brightness

echo XX > acpi_video0/brightness changes acpi_video0/brightness and acpi_video0/actual_brightness, but LCD brightness doesn't change.

I'm on a T61 8897 CTO with integrated graphics, with bios 2.17 (the latest atm). If you want dmesg, lspci, acpidump stuff, please ask.

Cheers,

Hmhm, is there any news on this stuff?

no. :(
we still don't have a solution for this problem

Created attachment 16673 [details]
Cleanup: Initialize brightness and display switching in separate functions

These three patches should fix the problem:
  - Make ThinkPads with Intel graphics card using the right device
  - Ignore devices not plugged in making Toshiba and other models work with
    video.ko
  - Fix possible double HW access when switching brightness through vendor
    specific drivers

Tested backlight switching on a ThinkPad T61 with discrete Nvidia and on a T61 with an internal Intel graphics card (without X!).

Please give them a try.

Created attachment 16674 [details]
ACPI: video: Ignore devices that aren't present in hardware

Created attachment 16675 [details]
Check for backlight support via ACPI video.ko otherwise use vendor ACPI drivers

All these are against Len's latest release git tree.

Some minor parts in thinkpad_acpi need cleanup if this should go in.
Henrique (and hopefully others) should have a look/review anyway.

Created attachment 16676 [details]
Oops, forgot to add this file. Now it should work

There still should be a compile error if video is not selected in .config, better enable it for testing

Created attachment 16694 [details]
Clean patch that replaces the last two.

We now have three patches:
  - Two more or less cleanups
  - One huge one that checks for video support in ACPI before any module gets
    loaded. Later (this is why so many drivers are affected) every vendor
    specific ACPI driver must check whether video.ko is going to do backlight
    switching or whether it can access the hardware.

I'll have a look at it soonish, just have to find some time to rebuild the kernel.

Looks like I won't be able to test it right now, since this patch does not apply against neither Fedora 9 nor Fedora rawhide kernels (which is probably not surprising) and I have no skills to build a git kernel.

Hah, I have a T61 here which can reproduce the problem.
I've tested the patches and it works well.
But I still have one question,
some IGD bios supports both IGD and legacy mode to change backlight,
which can be switched by acpi_osi="!Windows 2006".
But this patch removes the sys backlight interface for all ACPI video device once "DRDY" is found.

So, IMO, IGD support should not be involved in the second patch.
The first patch only causes regressions on T61 laptops (works for others like Toshiba) and a dmicheck can workaround the problem for now, even before the IGD Opregion patches are upstream, right?

Zhang, thanks a lot for testing and looking through this!

> So, IMO, IGD support should not be involved in the second patch.
Yes, I will remove it in the next version.
I thought the IGD support takes longer, but maybe now all works out.
It would still be nice to be able to switch backlight without IGD (e.g. if parts of the BIOS are missing as Matthew stated), but this could be added on top if needed, I like to make this as easy as possible for now to get it upstream.

Be careful the patch has a bug which can lead to a kernel oops:
+       acpi_bus_get_device(handle, &acpi_dev);
in find_video() must be checked for it's return value.

I will send the next version on the list.

> The first patch only causes regressions on T61 laptops
Matthew stated that it could cause regressions on other laptops, e.g. Panasonic as well. But he did not explain the details, I also consider it unlikely that we have more machines showing regressions on the initial patch (do not let video.ko access not physically available ACPI devices).

Re-assign this bug to Thomas.
And we can mark it as RESOLVED once Thomas has repost the patch set to linux-acpi.

*** Bug 10448 has been marked as a duplicate of this bug. ***

The code is in Andi's test branch, but won't make it into .27.
AFAIK policy is to set the bug to resolved already -> doing so.

Which branch are you talking about?
I cloned git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6.git but can't find any related commits there.
I came here from bug 10448 which was marked as duplicate and describes the freezing of a Samsung q45 on loading video.ko.
Unfortunately the latest code from the git repository above still freezes my samsung and the latest patch found in this bug-report doesn't run cleanly against 2.6.25.
Thanks in advance.

Try:
> git-clone git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-2.6
> acpi_test
> git-branch -r
> git-branch --track test origin/test
> git-checkout test
> git-log  # and search for the last change from trenn

With a kernel from that branch my Samsung q45 with intel graphics finally boots again without freezing while loading the video.ko-module.

Thanks!

shipped in 2.6.28-rc4-git3

closed.

commit 22c13f9d8179f4c9caecfcb60a95214562b9addc
Author: Thomas Renninger <trenn@suse.de>
Date:   Fri Aug 1 17:37:54 2008 +0200

    ACPI: video: Ignore devices that aren't present in hardware