NOTE : that 60% value is just a guess according to my visual perception ...

NOTE2: Unfortunately I don't know what debug info can help You in this case and how to colect it (I don't even know what backlight drivers are used in the mentioned kernels for the LCD in my laptop, but I am always willing to provide You with any information You need ... just tell me how to collect it. 

Thanks in advance!

(In reply to comment #2)
> NOTE2: Unfortunately I don't know what debug info can help You in this case
> and
> how to colect it (I don't even know what backlight drivers are used in the
> mentioned kernels for the LCD in my laptop, 

but at least you filed the bug in the correct category. :p

Please attach the acpidump output of your laptop.
please attach the output of "grep . /proc/acpi/video/*/*/brightness" in both 2.6.31 and 2.6.32 kernel.

Created attachment 25519 [details]
acpidump output

2.6.31.12>
[tavvva@TavvvaMini ~]$ grep . /proc/acpi/video/*/*/brightness
/proc/acpi/video/GFX0/DD01/brightness:<not supported>
/proc/acpi/video/GFX0/DD02/brightness:levels:  0 10 20 30 40 50 60 70 80 90 100
/proc/acpi/video/GFX0/DD02/brightness:current: 100
/proc/acpi/video/GFX0/DD03/brightness:<not supported>
/proc/acpi/video/GFX0/DD04/brightness:<not supported>
/proc/acpi/video/GFX0/DD05/brightness:<not supported>
/proc/acpi/video/GFX0/DD06/brightness:<not supported>
/proc/acpi/video/GFX0/DD07/brightness:<not supported>
/proc/acpi/video/GFX0/DD08/brightness:<not supported>

2.6.32>
[tavvva@TavvvaMini ~]$ grep . /proc/acpi/video/*/*/brightness

/proc/acpi/video/GFX0/DD01/brightness:<not supported>

/proc/acpi/video/GFX0/DD02/brightness:levels:  0 5 10 15 20 25 30 33 36 40 43 46 50 55 60 65 70 75 80 83 86 90 93 96 100

/proc/acpi/video/GFX0/DD02/brightness:current: 100

/proc/acpi/video/GFX0/DD03/brightness:<not supported>

/proc/acpi/video/GFX0/DD04/brightness:<not supported>

/proc/acpi/video/GFX0/DD05/brightness:<not supported>

/proc/acpi/video/GFX0/DD06/brightness:<not supported>

/proc/acpi/video/GFX0/DD07/brightness:<not supported>

/proc/acpi/video/GFX0/DD08/brightness:<not supported>

I've tried to sort the intensity levels in 2.6.31.12 and here's the result:

1,4,7,8,9,10,(6,5,3,2,0)

NOTE: levels 6,5,3,2,0 are very similar and it's very difficult to sort them correctly ... anyway ... 6,5,3,2,0 represent the highest brightness levels which are unreachable with kernel 2.6.32 (based on my visual perception) ... so maybe this can help You a bit with the problem identification

Thanks for Your answer.
Have a nice day!

does the problem still exist if you boot with boot option acpi_osi="!Windows 2009"?

Yes. I've tried several acpi_osi variants and the problem still persists ....

btw. I sorted the intensity levels incorrectly ... it's 1,4,7,8,10 and the rest is difficult to sort...

Created attachment 25602 [details]
debug patch

please apply this patch and attach the dmesg output after boot with acpi_osi="!Windows 2009"

Created attachment 25617 [details]
dmesg of 2.6.32 patched + acpi_osi="!Windows 2009"

dmesg of 2.6.32 patched + acpi_osi="!Windows 2009"

Created attachment 25618 [details]
dmesg of 2.6.31.12 patched + acpi_osi="!Windows 2009"

Hello.

I think You're interrested in the following dmesg parts:

---
Kernel command line: BOOT_IMAGE=2.6.32-1 root=UUID=f1e2d86b-8d63-4f01-9dc0-20e6fcbc7857  vga=791 acpi_osi="!Windows 2009"
Rui: acpi_osi=!Windows 2009
ACPI: Deleted _OSI(Windows 2009)
PID hash table entries: 4096 (order: 3, 32768 bytes)
---

---
Kernel command line: BOOT_IMAGE=2.6.31.12-1 root=UUID=f1e2d86b-8d63-4f01-9dc0-20e6fcbc7857  vga=791 acpi_osi="!Windows 2009"
Rui: acpi_osi=!Windows 2009
PID hash table entries: 4096 (order: 12, 32768 bytes)
---

Regards,
Jaromir.

Created attachment 25626 [details]
workaround script for kernel 2.6.31.12

>If anybody else is interrested in the problem workaround, 
>then copy the attached script to /usr/bin directory
>and define the following rules in /etc/sudoers 
>(replace "tavvva" with Your username):

# User alias specification
User_Alias BACKLIGHT_CTL_USERS = tavvva

# Cmnd alias specification
Cmnd_Alias BACKLIGHT_CTL_CMD = /usr/bin/backlight_ctl.sh

# Rules
BACKLIGHT_CTL_USERS     ALL = NOPASSWD: BACKLIGHT_CTL_CMD


>then assign the following commands to some keyboard shortcuts
>or simply call

sudo /usr/bin/backlight_ctl.sh up

>or

sudo /usr/bin/backlight_ctl.sh down

I found a very interresting workaround for 2.6.32 and higher:

The maximum brightness is reachable if I set the maximum possible brightness level in GRUB! (note: it works correctly in GRUB).
Brightness level set in GRUB always becomes the maximum brightness level reachable in Linux. It is like some floating window with some fixed reference level configurable in GRUB (or generally before booting the linux kernel). But if set the maximum brightness level in GRUB, than the lowest brightness levels become unreachable in Linux (...that's a logical consequence).

NOTE: There are 11 possible brightness levels in GRUB ....

Created attachment 25629 [details]
acpidump output on assus eeepc 1005PE

I have a similar bug with an assus eeepc 1005PE.
see https://qa.mandriva.com/show_bug.cgi?id=58285

grep . /proc/acpi/video/*/*/brightness
/proc/acpi/video/VGA/CRTD/brightness:<not supported>
/proc/acpi/video/VGA/LCDD/brightness:levels:  1 5 8 10 13 16 20 22 25 27 29 30
32 33 35 36
/proc/acpi/video/VGA/LCDD/brightness:current: 30
/proc/acpi/video/VGA/TVOD/brightness:<not supported>

(In reply to comment #11)
> Hello.
> 
> I think You're interrested in the following dmesg parts:
> 
> ---
> Kernel command line: BOOT_IMAGE=2.6.32-1
> root=UUID=f1e2d86b-8d63-4f01-9dc0-20e6fcbc7857  vga=791 acpi_osi="!Windows
> 2009"
> Rui: acpi_osi=!Windows 2009
> ACPI: Deleted _OSI(Windows 2009)
> PID hash table entries: 4096 (order: 3, 32768 bytes)
> ---
> 
> ---
> Kernel command line: BOOT_IMAGE=2.6.31.12-1
> root=UUID=f1e2d86b-8d63-4f01-9dc0-20e6fcbc7857  vga=791 acpi_osi="!Windows
> 2009"
> Rui: acpi_osi=!Windows 2009
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> ---
> 
that's okay. because Windows 2009 is not supported in 2.6.31

(In reply to comment #7)
> Yes. I've tried several acpi_osi variants and the problem still persists ....
> 
> btw. I sorted the intensity levels incorrectly ... it's 1,4,7,8,10 and the
> rest
> is difficult to sort...

I still think that acpi_osi="!Windows 2009" should fix the problem for you in 2.6.32.

could you please re-attach the dmesg output in 2.6.32, when booting with acpi_osi="!Windows 2009", and attach the output of "grep . /proc/acpi/video/*/*/*" in this kernel.

Created attachment 25641 [details]
NEW dmesg of 2.6.32 patched + acpi_osi="!Windows 2009"

Hello :)
Well ... It seems that I became untrusted :)

--------
[tavvva@TavvvaMini ~]$ grep . /proc/acpi/video/*/*/*
/proc/acpi/video/GFX0/DD01/brightness:<not supported>
/proc/acpi/video/GFX0/DD01/EDID:<not supported>
/proc/acpi/video/GFX0/DD01/info:device_id:    0x0001
/proc/acpi/video/GFX0/DD01/info:type:         UNKNOWN
/proc/acpi/video/GFX0/DD01/info:known by bios: no
/proc/acpi/video/GFX0/DD01/state:state:     0x1d
/proc/acpi/video/GFX0/DD01/state:query:     0x00
/proc/acpi/video/GFX0/DD02/brightness:levels:  0 10 20 30 40 50 60 70 80 90 100
/proc/acpi/video/GFX0/DD02/brightness:current: 100
/proc/acpi/video/GFX0/DD02/EDID:<not supported>
/proc/acpi/video/GFX0/DD02/info:device_id:    0x0002
/proc/acpi/video/GFX0/DD02/info:type:         UNKNOWN
/proc/acpi/video/GFX0/DD02/info:known by bios: no
/proc/acpi/video/GFX0/DD02/state:state:     0x1d
/proc/acpi/video/GFX0/DD02/state:query:     0x00
/proc/acpi/video/GFX0/DD03/brightness:<not supported>
/proc/acpi/video/GFX0/DD03/EDID:<not supported>
/proc/acpi/video/GFX0/DD03/info:device_id:    0x0300
/proc/acpi/video/GFX0/DD03/info:type:         UNKNOWN
/proc/acpi/video/GFX0/DD03/info:known by bios: no
/proc/acpi/video/GFX0/DD03/state:state:     0x1d
/proc/acpi/video/GFX0/DD03/state:query:     0x00
/proc/acpi/video/GFX0/DD04/brightness:<not supported>
/proc/acpi/video/GFX0/DD04/EDID:<not supported>
/proc/acpi/video/GFX0/DD04/info:device_id:    0x0301
/proc/acpi/video/GFX0/DD04/info:type:         UNKNOWN
/proc/acpi/video/GFX0/DD04/info:known by bios: no
/proc/acpi/video/GFX0/DD04/state:state:     0x1d
/proc/acpi/video/GFX0/DD04/state:query:     0x00
/proc/acpi/video/GFX0/DD05/brightness:<not supported>
/proc/acpi/video/GFX0/DD05/EDID:<not supported>
/proc/acpi/video/GFX0/DD05/info:device_id:    0x0302
/proc/acpi/video/GFX0/DD05/info:type:         UNKNOWN
/proc/acpi/video/GFX0/DD05/info:known by bios: no
/proc/acpi/video/GFX0/DD05/state:state:     0x1d
/proc/acpi/video/GFX0/DD05/state:query:     0x00
/proc/acpi/video/GFX0/DD06/brightness:<not supported>
/proc/acpi/video/GFX0/DD06/EDID:<not supported>
/proc/acpi/video/GFX0/DD06/info:device_id:    0x0006
/proc/acpi/video/GFX0/DD06/info:type:         UNKNOWN
/proc/acpi/video/GFX0/DD06/info:known by bios: no
/proc/acpi/video/GFX0/DD06/state:state:     0x0b
/proc/acpi/video/GFX0/DD06/state:query:     0x00
/proc/acpi/video/GFX0/DD07/brightness:<not supported>
/proc/acpi/video/GFX0/DD07/EDID:<not supported>
/proc/acpi/video/GFX0/DD07/info:device_id:    0x0007
/proc/acpi/video/GFX0/DD07/info:type:         UNKNOWN
/proc/acpi/video/GFX0/DD07/info:known by bios: no
/proc/acpi/video/GFX0/DD07/state:state:     0x0b
/proc/acpi/video/GFX0/DD07/state:query:     0x00
/proc/acpi/video/GFX0/DD08/brightness:<not supported>
/proc/acpi/video/GFX0/DD08/EDID:<not supported>
/proc/acpi/video/GFX0/DD08/info:device_id:    0x0008
/proc/acpi/video/GFX0/DD08/info:type:         UNKNOWN
/proc/acpi/video/GFX0/DD08/info:known by bios: no
/proc/acpi/video/GFX0/DD08/state:state:     0x0b
/proc/acpi/video/GFX0/DD08/state:query:     0x00
-------

It doesn't fix the issue ... You can see, that the number of brightness levels changed from 25 to 11, but the problem still persists ....

Maybe You lost in all the comments I produced ...

SHORT SUMMARY according to the latest findings....

GRUB>
-number of brightness levels: 11
-correct brightness order
-maximum brightness level reachable (at least I think it is the real maximum)
-minimum brightness level unreachable (this is difficult to explain ... it seems that on the low-level the LCD hardware supports intensities from absolute black upto the maximum reachable brightness, but only 11 selected values are used in the control functions of the BIOS)

2.6.31.12 MDV>
-number of brightness levels: 11
-mixed up brightness order (order depends on the initial brightness set in GRUB)
-even if I sort the intensity levels correctly, particular step sizes differ a lot (there are "holes" in the brightness setting) ... this also depends on the initial brightness set in GRUB, but the maximum brightness is usually somehow reachable)

2.6.32 MDV without acpi_osi="!Windows 2009">
-number of brightness levels: 25
-correct brightness order
-maximum and minimum brightness depends on the initial brightness set in GRUB
-when I set the maximum brightness in GRUB, the range configurable in Linux is [DARK -> BRIGHT]
-when I set the minimum brightness in GRUB, the range configurable in Linux is [VERY DARK -> DARK]

2.6.32 MDV with acpi_osi="!Windows 2009">
-it's like 2.6.32 with acpi_osi="!Windows 2009", but the number of brightness levels is 11 instead of 25

2.6.27.45 SuSE>
-number of brightness levels : 21
-maximum and minimum brightness depends on the initial brightness set in GRUB
-when I set the maximum brightness in GRUB, the range configurable in Linux is [DARK -> BRIGHT]
-when I set the minimum brightness in GRUB, the range configurable in Linux is [ABSOLUTE BLACK -> DARK]

-----------

As You can see ... it looks like the brightness values reachable in linux are relative to the initial brightness set in GRUB

NOTE: i forgot to write one detail

2.6.27.45 SuSE>
-correct brightness order

(In reply to comment #17)
> Created an attachment (id=25641) [details]
> NEW dmesg of 2.6.32 patched + acpi_osi="!Windows 2009"
> 
> Hello :)
> Well ... It seems that I became untrusted :)
> 
No, I didn't mean that. Sorry.

> --------
> [tavvva@TavvvaMini ~]$ grep . /proc/acpi/video/*/*/*
> /proc/acpi/video/GFX0/DD01/brightness:<not supported>
> /proc/acpi/video/GFX0/DD01/EDID:<not supported>
> /proc/acpi/video/GFX0/DD01/info:device_id:    0x0001
> /proc/acpi/video/GFX0/DD01/info:type:         UNKNOWN
> /proc/acpi/video/GFX0/DD01/info:known by bios: no
> /proc/acpi/video/GFX0/DD01/state:state:     0x1d
> /proc/acpi/video/GFX0/DD01/state:query:     0x00
> /proc/acpi/video/GFX0/DD02/brightness:levels:  0 10 20 30 40 50 60 70 80 90
> 100

I'm sure the no. of brightness levels should be changed, which is not mentioned in comment #7.
So I need to make a double check if I'm wrong at the first place. :p

(In reply to comment #18)
> SHORT SUMMARY according to the latest findings....
> 
> GRUB>
> -number of brightness levels: 11
> -correct brightness order
> -maximum brightness level reachable (at least I think it is the real maximum)
> -minimum brightness level unreachable (this is difficult to explain ... it
> seems that on the low-level the LCD hardware supports intensities from
> absolute
> black upto the maximum reachable brightness, but only 11 selected values are
> used in the control functions of the BIOS)
> 
> 2.6.31.12 MDV>
> -number of brightness levels: 11
> -mixed up brightness order (order depends on the initial brightness set in
> GRUB)
> -even if I sort the intensity levels correctly, particular step sizes differ
> a
> lot (there are "holes" in the brightness setting) ... this also depends on
> the
> initial brightness set in GRUB, but the maximum brightness is usually somehow
> reachable)
> 
> 2.6.32 MDV without acpi_osi="!Windows 2009">
> -number of brightness levels: 25
> -correct brightness order
> -maximum and minimum brightness depends on the initial brightness set in GRUB
> -when I set the maximum brightness in GRUB, the range configurable in Linux
> is
> [DARK -> BRIGHT]
> -when I set the minimum brightness in GRUB, the range configurable in Linux
> is
> [VERY DARK -> DARK]
> 
> 2.6.32 MDV with acpi_osi="!Windows 2009">
> -it's like 2.6.32 with acpi_osi="!Windows 2009", but the number of brightness
> levels is 11 instead of 25
> 
> 2.6.27.45 SuSE>
> -number of brightness levels : 21
> -maximum and minimum brightness depends on the initial brightness set in GRUB
> -when I set the maximum brightness in GRUB, the range configurable in Linux
> is
> [DARK -> BRIGHT]
> -when I set the minimum brightness in GRUB, the range configurable in Linux
> is
> [ABSOLUTE BLACK -> DARK]
> 
> -----------
> 
> As You can see ... it looks like the brightness values reachable in linux are
> relative to the initial brightness set in GRUB

this is strange.
please echo different values to /sys/class/backlight/acpi_video0/brightness, from 0 to (max_brightness - 1).
does the backlight change consistently?

please build a vanilla kernel 
1. with CONFIG_ACPI_DEBUG set
2. later than 2.6.33
and then we can do some investigation to see how the AML code works on this laptop.

>this is strange.
>please echo different values to /sys/class/backlight/acpi_video0/brightness,
from 0 to (max_brightness - 1).

Why from 0 yo max_brightness - 1 ?
It should be from 0 to max_brightness,
because if You have max_brightness = 10,
then You can set the values from 0 to 10
and thats 11 values in total :) Do You agree?

>does the backlight change consistently?

it works the same way like with brightness keys ...
that means function keys always increase resp. decrease
the /sys/class/backlight/acpi_video0/brightness by 1.
but the LCD brightness doesn't work according to 
these values in kernel 2.6.31.12 and lower ...

>please build a vanilla kernel 
>1. with CONFIG_ACPI_DEBUG set
>2. later than 2.6.33
>and then we can do some investigation to see how the AML code works on this
laptop.

I am gonna do that ...

And .... once I have it built ... what info would You like to have?

kernel 2.6.34.rc2 built with CONFIG_ACPI_DEBUG set ...

Created attachment 25675 [details]
custom _BCM method with more debug info

please boot with acpi.debug_level=0x06 acpi.debug_layer=0x80,
and then
1. mount debugfs by "mount -t debugfs none /sys/kernel/debug"
2. override the _BCM method via the debugfs by running
      "cat _BCM.aml > /sys/kernel/debug/acpi/custom_method"
3. echo {0, 1, 2, ..., max_brightness} > /sys/class/backlight/acpi_video0/brightness
4. attach the dmesg output.

Ok ... I will do that during lunch break ... 

One note ... I found a quite logical difference in behavior between HP Mini 5102 and my second Lenovo R61 laptop where the brightness works according to my expectations ... 

Lenovo R61>
If I set the maximum brightness in GRUB, then boot into Linux, cat /sys/class/backlight/acpi_video0/brightness gives me the same value like /sys/class/backlight/acpi_video0/max_brightness.
If I set the minimum brightness in GRUB, then boot into Linux, cat /sys/class/backlight/acpi_video0/brightness gives 0.

HP Mini 5102>
/sys/class/backlight/acpi_video0/brightness is always set to /sys/class/backlight/acpi_video0/max_brightness regardless of the brightness set in GRUB (even if the brightness in GRUB is set to minimum) ..... this allows me to decrease the value  more than the allowed minimum in GRUB ... but as a consequence I cannot raise it more than the brightness set in GRUB ...

but ... the behavior mentioned in my previous comment applies on kernels 2.6.32 and higher only ....

(In reply to comment #25)
> Ok ... I will do that during lunch break ... 
> 
> One note ... I found a quite logical difference in behavior between HP Mini
> 5102 and my second Lenovo R61 laptop where the brightness works according to
> my
> expectations ... 
> 
> Lenovo R61>
> If I set the maximum brightness in GRUB, then boot into Linux, cat
> /sys/class/backlight/acpi_video0/brightness gives me the same value like
> /sys/class/backlight/acpi_video0/max_brightness.
> If I set the minimum brightness in GRUB, then boot into Linux, cat
> /sys/class/backlight/acpi_video0/brightness gives 0.
> 
does the brightness is at low level as well?

yes ... if i set the minimum brightness in GRUB, then it stays at the low level on both computers ...

the only difference is in initial /sys/class/backlight/acpi_video0/brightness value .... HP Mini 5102 has the value initially always set to /sys/class/backlight/acpi_video0/max_brightness regardless of the current brightness (configured in GRUB) and next changes are relative to this brightness level (and since the /sys/class/backlight/acpi_video0/brightness is set to the maximum value, the brightness could be only decreased ... even if it is not at it's maximum .... and can be decreased much more than it is allowed in GRUB) .... it's difficult to explain that ... and unfortunately it is not possible to record the behavior because of automatic exposition control in my camera ... I could try that with some lights around my laptop + tripod ...

Btw. I have tried to collect the dmesg output, but there's too much info and the output is always cut to 126kB + something.
Should I create more dmesg outputs for the particular "echo" calls?

J.

Created attachment 25682 [details]
dmesg of the acpi debug

I used the following script to collect the particular dmesg outputs for maximum brightness set in GRUB and for the minimum brightness set in grub ...
differences are seen with diff/kdiff3 ...

#!/bin/bash
mount -t debugfs none /sys/kernel/debug
sleep 1
cat _BCM.aml > /sys/kernel/debug/acpi/custom_method
sleep 1

dmesg > ./dmesg/initial.txt

max_brightness=`cat /sys/class/backlight/acpi_video0/max_brightness`
cur_brightness=0

while [ $cur_brightness -lt $max_brightness ]; do
  echo $cur_brightness > /sys/class/backlight/acpi_video0/brightness
  sleep 1
  dmesg > ./dmesg/$cur_brightness.txt
  let cur_brightness=cur_brightness+1
done

Created attachment 25683 [details]
dmesg of the acpi debug - new

I used wrong condition in the previous version of the script

... condition changed from -lt to -le ...

Created attachment 25688 [details]
dmesg diffs

I created the following script to cut the acpi debug parts associated with each "echo" call ...

#!/bin/bash

max_brightness=24
cur_brightness=0

old_filename="./initial.txt"

while [ $cur_brightness -le $max_brightness ]; do
  new_filename="./$cur_brightness.txt"
  diff -u $old_filename $new_filename | grep "^+" | awk "FNR>2"  | sed 's/^+//g' > diff_$cur_brightness.txt
  old_filename=$new_filename
  let cur_brightness=cur_brightness+1
done

values 14 and higher seems to cause strange behavior ... they produce so much debug info, that it doesn't fit into the 126kB dmesg window and the diff fails ...

(In reply to comment #33)
> values 14 and higher seems to cause strange behavior ... they produce so much
> debug info,

please boot with acpi.debug_layer=0x80 acpi.debug_level=0x2002 this time and do the same test.

(In reply to comment #34)
> (In reply to comment #33)
> > values 14 and higher seems to cause strange behavior ... they produce so
> much
> > debug info,
> 
> please boot with acpi.debug_layer=0x80 acpi.debug_level=0x2002 this time and
> do
> the same test.

which will produce less info, but more valuable.

Created attachment 25704 [details]
dmesg - acpi.debug_layer=0x80 acpi.debug_level=0x2002

Much better! 

But ... 
Arg0 values go from 0 to 100 in both cases and the real brightness is different ... check the final.txt or particular diffs.

it seems that the IGD OpeRegion is not working correctly...

Hello Rui.

Any news here?

ACPI is invoking IGD Opregion stuff correctly.

Yakui, can you help debugging this issue?

hi, Jaromir
sorry for the late response.
does the bug still exist in the latest upstream kernel?