Thread: extent brightness adjust in 2.6.18?
Brought to you by:
matthiasgrimm
Menu
▾
▴
pbbuttons-users
|
From: timotheus <pbb...@ts...> - 2006-09-22 00:50:01
|
Hi,
There is a small issue with pbbuttonsd and kernel version 2.6.18.
Adjusting the LCD brightness works *only* when compiled with the new
option:
CONFIG_FB_RADEON_BACKLIGHT=y
However, I think that the kernel remains in control of the F1/F2
brightness buttons and does not let pbbuttonsd read the button. The
shift-F1/F2-key does not increase/decrease the brightness to
maximum/minimum extent like it does with kernels 2.6.17 and
older. Instead, it only increments/decrements by one level of
brightness, the same as if no shift-key is held.
This is the same regardless of KBDMode, but that is expected on my ADB
keyboard. Details of the powerbook in question are at:
http://tstotts.net/linux/gentoopb.html
Regards,
timotheus
|
|
From: timotheus <pbb...@ts...> - 2006-09-23 16:10:49
|
This is fixed with kernel option:
CONFIG_PMAC_BACKLIGHT_LEGACY=y
>However, I think that the kernel remains in control of the F1/F2
>brightness buttons and does not let pbbuttonsd read the button.
Perhaps a new pbbuttonsd will be updated to use /sys/class/backlight/
instead of the PMU?
Regards,
timotheus
|
|
From: Yves-Alexis P. <co...@co...> - 2006-09-27 08:44:12
|
On Sat, 2006-09-23 at 12:10 -0400, timotheus wrote: > This is fixed with kernel option: > CONFIG_PMAC_BACKLIGHT_LEGACY=y > > >However, I think that the kernel remains in control of the F1/F2 > >brightness buttons and does not let pbbuttonsd read the button. > > Perhaps a new pbbuttonsd will be updated to use /sys/class/backlight/ > instead of the PMU? Is there any news on this ? Do you need help ? (I may look at the code but don't really know where to start) -- Yves-Alexis |
|
From: Matthias G. <mat...@us...> - 2006-09-24 09:39:27
|
On Sat, 23 Sep 2006 12:10:41 -0400 timotheus <pbb...@ts...> wrote: > This is fixed with kernel option: > CONFIG_PMAC_BACKLIGHT_LEGACY=y > > >However, I think that the kernel remains in control of the F1/F2 > >brightness buttons and does not let pbbuttonsd read the button. > > Perhaps a new pbbuttonsd will be updated to use /sys/class/backlight/ > instead of the PMU? Yes it will. I am just working on that. Maybe you could help me a bit and answer some questions. 1. Do you see more than one entry in /sys/class/backlight? 2. If so, what are they for? 3. Has the keyboard backlight an entry in /sys/class/backlight too? I studied the kernel source and found no clue for that but I might have missed something. Best Regards Matthias |
|
From: Yves-Alexis P. <co...@co...> - 2006-09-24 10:23:11
|
On Sun, 2006-09-24 at 10:45 +0200, Matthias Grimm wrote: > Yes it will. I am just working on that. Maybe you could help me a bit > and answer some questions. > > 1. Do you see more than one entry in /sys/class/backlight? I'm running 2.6.18-rc6 on a powerbook 5,6 (keyboard backlight present and working) corsac@hidalgo: ls -R /sys/class/backlight [~] /sys/class/backlight: total 0 drwxr-xr-x 2 root root 0 1904-01-01 00:10 radeonbl0 /sys/class/backlight/radeonbl0: total 0 -r--r--r-- 1 root root 4.0K 2006-09-24 12:20 actual_brightness -rw-r--r-- 1 root root 4.0K 2006-09-24 12:20 brightness -r--r--r-- 1 root root 4.0K 2006-09-24 12:20 max_brightness -rw-r--r-- 1 root root 4.0K 2006-09-24 12:20 power lrwxrwxrwx 1 root root 0 2006-09-24 12:20 subsystem -> ../../../class/backlight --w------- 1 root root 4.0K 2006-09-24 12:20 uevent > 2. If so, what are they for? > 3. Has the keyboard backlight an entry in /sys/class/backlight too? No it seems not (but maybe I'm lacking some config option) > I studied the kernel source and found no clue for that but I might > have missed something. > Regards; -- Yves-Alexis |
|
From: timotheus <pbb...@ts...> - 2006-09-27 17:54:16
|
>>
>> 1. Do you see more than one entry in /sys/class/backlight?
>
For me, I have a PowerBook5,2 running kernel 2.6.18 (with unrelated
patches).
>corsac@hidalgo: ls -R /sys/class/backlight [~]
>/sys/class/backlight:
>total 0
>drwxr-xr-x 2 root root 0 1904-01-01 00:10 radeonbl0
>
>/sys/class/backlight/radeonbl0:
>total 0
>-r--r--r-- 1 root root 4.0K 2006-09-24 12:20 actual_brightness
>-rw-r--r-- 1 root root 4.0K 2006-09-24 12:20 brightness
>-r--r--r-- 1 root root 4.0K 2006-09-24 12:20 max_brightness
>-rw-r--r-- 1 root root 4.0K 2006-09-24 12:20 power
>lrwxrwxrwx 1 root root 0 2006-09-24 12:20 subsystem
>-> ../../../class/backlight
Same for me.
>
>> 2. If so, what are they for?
>> 3. Has the keyboard backlight an entry in /sys/class/backlight too?
>
>No it seems not (but maybe I'm lacking some config option)
>
>> I studied the kernel source and found no clue for that but I might
>> have missed something.
My subjective impression from the code and recent kernel trends:
The keyboard is unrelated. This is a kernel reworking to have a
backlight class for all LCD backlights. Radeon is one of the first,
but not to be the only, driver with the same backlight sysfs
interface. This allows independence of the PMU driver and merging of
PC and Mac code. This information is somewhat mentioned in the driver
help (make menuconfig , help items).
I have no part in developing this driver, but from experimentation
I have determined the following.
The 'actual_brightness' file is read-only and seems to always have the
same value as 'brightness'.
The 'brightness' file is writable and immediately adjusts the
LCD. Appropriate values are 0 (full dark), 1 (min. brightness), to the
value of 'max_brightness', which is 127 on this laptop.
'max_brightness' is the maximum value allowed to be written to
'brightness', otherwise an error is displayed on the terminal:
# echo 128 > brightness
bash: echo: write error: Invalid argument
'power' has the value of 0, seemingly always.
Relation to current pbbuttonsd release 0.7.8:
pbb value , sysfs-brightness value
1 , 8
2 , 16
3 , 24
4 , 32
5 , 40
6 , 48
7 , 56
8 , 64
9 , 72
10 , 80
11 , 88
12 , 96
13 , 104
14 , 112
15 , 120
The sysfs brightness value *does* smoothly adjust the LCD by each
increment from 0 to 127, as demonstrated with the command:
# (for n in `seq 1 127`; do echo $n > brightness; sleep .05s; done)
One interesting note. Pbbuttonsd 0.7.x has a bug that sometimes
occurs by leaving the machine idle for hours and then returning to
using it. The display remains at maximum brightness and
does not respond to F1/F2 adjustments until using these keys to adjust
to full-dark, and then increasing brightness again.
When this bug is active, the display brightness value is '127'. But,
the maximum value pbbuttonsd sets by using F1/F2 is '120'. I assume
that this bug will disappear when using the sysfs interface anyways,
but thought it interesting.
Best regards,
timotheus
|
|
From: Matthias G. <mat...@us...> - 2006-09-29 18:43:45
|
On Wed, 27 Sep 2006 01:15:27 -0400
timotheus <pbb...@ts...> wrote:
> The 'actual_brightness' file is read-only and seems to always have the
> same value as 'brightness'.
>
> The 'brightness' file is writable and immediately adjusts the
> LCD. Appropriate values are 0 (full dark), 1 (min. brightness), to the
> value of 'max_brightness', which is 127 on this laptop.
>
> 'max_brightness' is the maximum value allowed to be written to
> 'brightness', otherwise an error is displayed on the terminal:
I found the same. Pbbuttons will use max_brightness and brightness.
> The sysfs brightness value *does* smoothly adjust the LCD by each
> increment from 0 to 127, as demonstrated with the command:
The release candidate of pbbuttonsd (in CVS) uses all supported
brightness levels so we don't need a transformation table or something
like that.
> One interesting note. Pbbuttonsd 0.7.x has a bug that sometimes
> occurs by leaving the machine idle for hours and then returning to
> using it. The display remains at maximum brightness and
> does not respond to F1/F2 adjustments until using these keys to adjust
> to full-dark, and then increasing brightness again.
>
> When this bug is active, the display brightness value is '127'. But,
> the maximum value pbbuttonsd sets by using F1/F2 is '120'. I assume
> that this bug will disappear when using the sysfs interface anyways,
> but thought it interesting.
Never heard about this before.
- Was the display dimmed or completely dark before you re-using it?
- What about sleep mode? Did the machine idle all the time?
- Was the option UseFBBblank activated in your configuration?
Try to set UseFBBlank = "no". New PowerBooks were reported to have
problems with this option and I think recent kernels don't need it any
longer anyway.
Please tell me if that behaviour is fixed with the release candidate.
Best Regards
Matthias
|
|
From: timotheus <pbb...@ts...> - 2006-09-27 17:54:19
|
Resending due to local mail issues. Sorry if this becomes a duplicate post.
>>
>> 1. Do you see more than one entry in /sys/class/backlight?
>
For me, I have a PowerBook5,2 running kernel 2.6.18 (with unrelated
patches).
>corsac@hidalgo: ls -R /sys/class/backlight [~]
>/sys/class/backlight:
>total 0
>drwxr-xr-x 2 root root 0 1904-01-01 00:10 radeonbl0
>
>/sys/class/backlight/radeonbl0:
>total 0
>-r--r--r-- 1 root root 4.0K 2006-09-24 12:20 actual_brightness
>-rw-r--r-- 1 root root 4.0K 2006-09-24 12:20 brightness
>-r--r--r-- 1 root root 4.0K 2006-09-24 12:20 max_brightness
>-rw-r--r-- 1 root root 4.0K 2006-09-24 12:20 power
>lrwxrwxrwx 1 root root 0 2006-09-24 12:20 subsystem
>-> ../../../class/backlight
Same for me.
>
>> 2. If so, what are they for?
>> 3. Has the keyboard backlight an entry in /sys/class/backlight too?
>
>No it seems not (but maybe I'm lacking some config option)
>
>> I studied the kernel source and found no clue for that but I might
>> have missed something.
My subjective impression from the code and recent kernel trends:
The keyboard is unrelated. This is a kernel reworking to have a
backlight class for all LCD backlights. Radeon is one of the first,
but not to be the only, driver with the same backlight sysfs
interface. This allows independence of the PMU driver and merging of
PC and Mac code. This information is somewhat mentioned in the driver
help (make menuconfig , help items).
I have no part in developing this driver, but from experimentation
I have determined the following.
The 'actual_brightness' file is read-only and seems to always have the
same value as 'brightness'.
The 'brightness' file is writable and immediately adjusts the
LCD. Appropriate values are 0 (full dark), 1 (min. brightness), to the
value of 'max_brightness', which is 127 on this laptop.
'max_brightness' is the maximum value allowed to be written to
'brightness', otherwise an error is displayed on the terminal:
# echo 128 > brightness
bash: echo: write error: Invalid argument
'power' has the value of 0, seemingly always.
Relation to current pbbuttonsd release 0.7.8:
pbb value , sysfs-brightness value
1 , 8
2 , 16
3 , 24
4 , 32
5 , 40
6 , 48
7 , 56
8 , 64
9 , 72
10 , 80
11 , 88
12 , 96
13 , 104
14 , 112
15 , 120
The sysfs brightness value *does* smoothly adjust the LCD by each
increment from 0 to 127, as demonstrated with the command:
# (for n in `seq 1 127`; do echo $n > brightness; sleep .05s; done)
One interesting note. Pbbuttonsd 0.7.x has a bug that sometimes
occurs by leaving the machine idle for hours and then returning to
using it. The display remains at maximum brightness and
does not respond to F1/F2 adjustments until using these keys to adjust
to full-dark, and then increasing brightness again.
When this bug is active, the display brightness value is '127'. But,
the maximum value pbbuttonsd sets by using F1/F2 is '120'. I assume
that this bug will disappear when using the sysfs interface anyways,
but thought it interesting.
Best regards,
timotheus
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X