[opensuse] 13.1 - screen brightness stuck on high - unresponsive to fn keys - how to fix?
All, One new issue I have with 13.1 is my Toshiba laptop brightness is stuck on high (really high) and I cannot adjust it with the normal function keys. The normal method for increase/decrease is: fn + F6 - lower (8 steps) fn + F7 - raise (8 steps) What is strange is that this hardware brightness control has always worked, regardless of the OS (XP/DOS, openSuSE 11.0, 11.4, Archlinux) and regardless of the driver (radeon, radeonHD, etc..) Now it is just stuck. I can pop the 11.4 drive back in and it works fine. What could be causing this? Moreover, what could be the fix? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon 14 Jul 2014 11:35:51 AM CDT, David C. Rankin wrote:
All,
One new issue I have with 13.1 is my Toshiba laptop brightness is stuck on high (really high) and I cannot adjust it with the normal function keys. The normal method for increase/decrease is:
fn + F6 - lower (8 steps) fn + F7 - raise (8 steps)
What is strange is that this hardware brightness control has always worked, regardless of the OS (XP/DOS, openSuSE 11.0, 11.4, Archlinux) and regardless of the driver (radeon, radeonHD, etc..)
Now it is just stuck. I can pop the 11.4 drive back in and it works fine. What could be causing this? Moreover, what could be the fix?
Hi Is the backlight service running? systemctl status systemd-backlight@acpi_video0.service or something similar? On my HP ProBook 4440s I had to add an acpi boot option(UEFI and secure boot on); acpi_osi=\"!Windows 2012\" -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE 13.1 (Bottle) (x86_64) 3.10.1 Kernel 3.11.10-17-desktop up 3 days 5:14, 6 users, load average: 0.03, 0.03, 0.05 CPU Intel® B840@1.9GHz | GPU Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2014 02:55 PM, Malcolm wrote:
On Mon 14 Jul 2014 11:35:51 AM CDT, David C. Rankin wrote:
All,
One new issue I have with 13.1 is my Toshiba laptop brightness is stuck on high (really high) and I cannot adjust it with the normal function keys. The normal method for increase/decrease is:
fn + F6 - lower (8 steps) fn + F7 - raise (8 steps)
What is strange is that this hardware brightness control has always worked, regardless of the OS (XP/DOS, openSuSE 11.0, 11.4, Archlinux) and regardless of the driver (radeon, radeonHD, etc..)
Now it is just stuck. I can pop the 11.4 drive back in and it works fine. What could be causing this? Moreover, what could be the fix?
Hi Is the backlight service running? systemctl status systemd-backlight@acpi_video0.service
or something similar?
On my HP ProBook 4440s I had to add an acpi boot option(UEFI and secure boot on);
acpi_osi=\"!Windows 2012\"
Malcolm, Thanks. Yep, it is running, it is just not setting the correct values in /sys/class/backlight: systemctl status systemd-backlight@acpi_video0.service systemd-backlight@acpi_video0.service - Load/Save Screen Backlight Brightness of acpi_video0 Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static) Active: active (exited) since Mon 2014-07-14 05:44:51 CDT; 10h ago Docs: man:systemd-backlight@.service(8) Process: 335 ExecStart=/usr/lib/systemd/systemd-backlight load %I (code=exited, status=0/SUCCESS) Main PID: 335 (code=exited, status=0/SUCCESS) Jul 14 05:44:51 alchemy systemd[1]: Starting Load/Save Screen Backlight Brightness of acpi_video0... Jul 14 05:44:51 alchemy systemd[1]: Started Load/Save Screen Backlight Brightness of acpi_video0. I don't know if this is normal, but I have 2 entries under /sys/class/backlight?? Look at my response to Peter for full details. It looks like the correct value that needs to be set is /sys/class/backlight/acpi_video0/brightness. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday 14 of July 2014 11:35:51 David C. Rankin wrote:
One new issue I have with 13.1 is my Toshiba laptop brightness is stuck on high (really high) and I cannot adjust it with the normal function keys. Now it is just stuck. I can pop the 11.4 drive back in and it works fine. What could be causing this? Moreover, what could be the fix?
Could you try setting the value in /sys/class/backlight/*/brightness to see whether the keys are registered to set the brightness level or not? For example, on my computer echo 100 > /sys/class/backlight/intel_backlight/brightness reduces backlight to low level and cat /sys/class/backlight/intel_backlight/brightness_max yields the maximum. If this works, probably some kernel module or special setting is required for the kernel to handle the special keys. -- Regards, Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2014 03:23 PM, auxsvr@gmail.com wrote:
On Monday 14 of July 2014 11:35:51 David C. Rankin wrote:
One new issue I have with 13.1 is my Toshiba laptop brightness is stuck on high (really high) and I cannot adjust it with the normal function keys. Now it is just stuck. I can pop the 11.4 drive back in and it works fine. What could be causing this? Moreover, what could be the fix? Could you try setting the value in/sys/class/backlight/*/brightness to see whether the keys are registered to set the brightness level or not? For example, on my computer
echo 100 > /sys/class/backlight/intel_backlight/brightness
reduces backlight to low level and
cat /sys/class/backlight/intel_backlight/brightness_max
yields the maximum. If this works, probably some kernel module or special setting is required for the kernel to handle the special keys.
Hmm.., Now we are getting somewhere. This is interesting: $ ll /sys/class/backlight/ total 0 lrwxrwxrwx 1 root root 0 Jul 14 15:34 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:05.0/backlight/acpi_video0 lrwxrwxrwx 1 root root 0 Jul 14 15:34 radeon_bl0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm/card0/card0-LVDS-1/radeon_bl0 So I have 2 entries under /sys/class/backlight. The first acpi_video0: $ l /sys/class/backlight/acpi_video0/ drwxr-xr-x 2 root root 0 Jul 14 10:56 power -r--r--r-- 1 root root 4096 Jul 14 10:56 actual_brightness -rw-r--r-- 1 root root 4096 Jul 14 10:56 bl_power -rw-r--r-- 1 root root 4096 Jul 14 15:36 brightness lrwxrwxrwx 1 root root 0 Jul 14 10:56 device -> ../../../0000:01:05.0 -r--r--r-- 1 root root 4096 Jul 14 10:56 max_brightness lrwxrwxrwx 1 root root 0 Jul 14 15:36 subsystem -> ../../../../../../class/backlight -r--r--r-- 1 root root 4096 Jul 14 15:36 type -rw-r--r-- 1 root root 4096 Jul 14 15:36 uevent $ cat /sys/class/backlight/acpi_video0/brightness 7 and the second radeon_bl0: l /sys/class/backlight/radeon_bl0/ total 0 drwxr-xr-x 3 root root 0 Jul 14 05:44 . drwxr-xr-x 4 root root 0 Jul 14 05:44 .. drwxr-xr-x 2 root root 0 Jul 14 10:56 power -r--r--r-- 1 root root 4096 Jul 14 10:56 actual_brightness -rw-r--r-- 1 root root 4096 Jul 14 10:56 bl_power -rw-r--r-- 1 root root 4096 Jul 14 10:56 brightness lrwxrwxrwx 1 root root 0 Jul 14 10:56 device -> ../../card0-LVDS-1 -r--r--r-- 1 root root 4096 Jul 14 10:56 max_brightness lrwxrwxrwx 1 root root 0 Jul 14 10:56 subsystem -> ../../../../../../../../class/backlight -r--r--r-- 1 root root 4096 Jul 14 16:00 type -rw-r--r-- 1 root root 4096 Jul 14 16:00 uevent $ cat /sys/class/backlight/radeon_bl0/brightness 0 Judging from the values, /sys/class/backlight/acpi_video0/brightness is the correct one and a value of 7 is the brightest of the 8 steps [0-8]. Testing: # for i in `seq 0 7`; do echo $i > /sys/class/backlight/acpi_video0/brightness; sleep 1; done Steps perfectly through all 8 levels of brightness. How do we get the fn keys to work properly? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2014 04:09 PM, David C. Rankin wrote:
On 07/14/2014 03:23 PM, auxsvr@gmail.com wrote:
On Monday 14 of July 2014 11:35:51 David C. Rankin wrote:
One new issue I have with 13.1 is my Toshiba laptop brightness is stuck on high (really high) and I cannot adjust it with the normal function keys. Now it is just stuck. I can pop the 11.4 drive back in and it works fine. What could be causing this? Moreover, what could be the fix? Could you try setting the value in/sys/class/backlight/*/brightness to see whether the keys are registered to set the brightness level or not? For example, on my computer
echo 100 > /sys/class/backlight/intel_backlight/brightness
reduces backlight to low level and
cat /sys/class/backlight/intel_backlight/brightness_max
yields the maximum. If this works, probably some kernel module or special setting is required for the kernel to handle the special keys.
Hmm..,
Now we are getting somewhere. This is interesting:
$ ll /sys/class/backlight/ total 0 lrwxrwxrwx 1 root root 0 Jul 14 15:34 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:05.0/backlight/acpi_video0 lrwxrwxrwx 1 root root 0 Jul 14 15:34 radeon_bl0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm/card0/card0-LVDS-1/radeon_bl0
<snip>
Judging from the values, /sys/class/backlight/acpi_video0/brightness is the correct one and a value of 7 is the brightest of the 8 steps [0-8]. Testing:
# for i in `seq 0 7`; do echo $i > /sys/class/backlight/acpi_video0/brightness; sleep 1; done
Steps perfectly through all 8 levels of brightness. How do we get the fn keys to work properly?
Ugly temporary hack: #!/bin/bash test -n "$1" || { printf "error insufficient input, usage %s int [0-7] (screen brightness)\n" "${0//*\//}" exit 1 } test "$1" -ge 0 && test "$1" -lt 8 || { printf "error invalid argument, usage %s int [0-7] (screen brightness)\n" "${0//*\//}" exit 1 } if test "$UID" -eq 0 ; then echo $1 > /sys/class/backlight/acpi_video0/brightness else sudo bash -c "echo $1 > /sys/class/backlight/acpi_video0/brightness" fi exit 0 -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday 14 of July 2014 16:09:07 David C. Rankin wrote:
Judging from the values, /sys/class/backlight/acpi_video0/brightness is the correct one and a value of 7 is the brightest of the 8 steps [0-8]. Testing:
# for i in `seq 0 7`; do echo $i > /sys/class/backlight/acpi_video0/brightness; sleep 1; done
Steps perfectly through all 8 levels of brightness. How do we get the fn keys to work properly?
Try running acpi_listen as root. Does any of the brightness keys trigger an event? If not, then the toshiba_acpi kernel module for Toshiba laptops should be loaded. If it is already loaded, are there any related error messages in the system log? It's too late here, I'll be going to sleep shortly. -- Regards, Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2014 04:51 PM, auxsvr@gmail.com wrote:
On Monday 14 of July 2014 16:09:07 David C. Rankin wrote:
Judging from the values, /sys/class/backlight/acpi_video0/brightness is the correct one and a value of 7 is the brightest of the 8 steps [0-8]. Testing:
# for i in `seq 0 7`; do echo $i > /sys/class/backlight/acpi_video0/brightness; sleep 1; done
Steps perfectly through all 8 levels of brightness. How do we get the fn keys to work properly?
Try running acpi_listen as root. Does any of the brightness keys trigger an event? If not, then the toshiba_acpi kernel module for Toshiba laptops should be loaded. If it is already loaded, are there any related error messages in the system log?
It's too late here, I'll be going to sleep shortly.
We are making progress: [16:35 alchemy:/home/david] # acpi_listen bash: acpi_listen: command not found Huh? What am I missing? Go to bed, thanks for your help and we will work more on it tomorrow :-) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/07/14 19:34, David C. Rankin wrote:
On 07/14/2014 04:51 PM, auxsvr@gmail.com wrote:
On Monday 14 of July 2014 16:09:07 David C. Rankin wrote:
Judging from the values, /sys/class/backlight/acpi_video0/brightness is the correct one and a value of 7 is the brightest of the 8 steps [0-8]. Testing:
# for i in `seq 0 7`; do echo $i > /sys/class/backlight/acpi_video0/brightness; sleep 1; done
Steps perfectly through all 8 levels of brightness. How do we get the fn keys to work properly?
Try running acpi_listen as root. Does any of the brightness keys trigger an event? If not, then the toshiba_acpi kernel module for Toshiba laptops should be loaded. If it is already loaded, are there any related error messages in the system log?
It's too late here, I'll be going to sleep shortly.
We are making progress:
[16:35 alchemy:/home/david] # acpi_listen bash: acpi_listen: command not found
On my 12.3 box, rpm tells me: # rpm -q --whatprovides /usr/bin/acpi_listen acpid-2.0.17-2.4.1.x86_64 HTH, Alvin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2014 05:53 PM, Alvin Beach wrote:
On my 12.3 box, rpm tells me:
# rpm -q --whatprovides /usr/bin/acpi_listen
acpid-2.0.17-2.4.1.x86_64
HTH,
Alvin
Thank you Alvin, Indeed - for some reason, acpid was not installed during the 13.1 install. That is strange, I have never had to manually select it before -- that I know. I'll give it a go. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/14/2014 08:28 PM, David C. Rankin wrote:
On 07/14/2014 05:53 PM, Alvin Beach wrote:
On my 12.3 box, rpm tells me:
# rpm -q --whatprovides /usr/bin/acpi_listen
acpid-2.0.17-2.4.1.x86_64
HTH,
Alvin
Thank you Alvin,
Indeed - for some reason, acpid was not installed during the 13.1 install. That is strange, I have never had to manually select it before -- that I know. I'll give it a go.
I installed acpid, and started it $ sudo systemctl start apcid confirm: $ jcnl -n 50 Jul 14 20:29:50 alchemy.3111skyline.com systemd[1]: Starting ACPI Event Daemon... Jul 14 20:29:50 alchemy.3111skyline.com systemd[1]: Started ACPI Event Daemon. Jul 14 20:29:50 alchemy.3111skyline.com acpid[18515]: starting up with netlink and the input layer Jul 14 20:29:50 alchemy.3111skyline.com acpid[18515]: 1 rule loaded Jul 14 20:29:50 alchemy.3111skyline.com acpid[18515]: waiting for events: event logging is off Testing acpi_listen: $ acpi_listen video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K ^\Quit Hmm. So the keystrokes are seen with acpid running, but it has no effect on the brightness. So it looks like we need to create hooks or a config for the events. But where? /etc/acpi/events? This is the first time with any openSuSE distro I've had to manually connect acpid event with screen brightness. If I need to create a config somewhere else, please let me know, if not, I'll go look at the events file. Thanks. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/07/14 03:52, David C. Rankin wrote:
On 07/14/2014 08:28 PM, David C. Rankin wrote:
On 07/14/2014 05:53 PM, Alvin Beach wrote:
On my 12.3 box, rpm tells me:
# rpm -q --whatprovides /usr/bin/acpi_listen
acpid-2.0.17-2.4.1.x86_64
HTH,
Alvin
Thank you Alvin,
Indeed - for some reason, acpid was not installed during the 13.1 install. That is strange, I have never had to manually select it before -- that I know. I'll give it a go.
I installed acpid, and started it
$ sudo systemctl start apcid
confirm:
$ jcnl -n 50
Jul 14 20:29:50 alchemy.3111skyline.com systemd[1]: Starting ACPI Event Daemon... Jul 14 20:29:50 alchemy.3111skyline.com systemd[1]: Started ACPI Event Daemon. Jul 14 20:29:50 alchemy.3111skyline.com acpid[18515]: starting up with netlink and the input layer Jul 14 20:29:50 alchemy.3111skyline.com acpid[18515]: 1 rule loaded Jul 14 20:29:50 alchemy.3111skyline.com acpid[18515]: waiting for events: event logging is off
Testing acpi_listen:
$ acpi_listen video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K ^\Quit
Hmm. So the keystrokes are seen with acpid running, but it has no effect on the brightness. So it looks like we need to create hooks or a config for the events. But where? /etc/acpi/events? This is the first time with any openSuSE distro I've had to manually connect acpid event with screen brightness. If I need to create a config somewhere else, please let me know, if not, I'll go look at the events file. Thanks.
David, is this of any use to you? Just spotted it on KDE-Apps.org updates: http://kde-apps.org/content/show.php/KToshiba?content=18621 Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/15/2014 03:49 AM, Peter wrote:
David, is this of any use to you? Just spotted it on KDE-Apps.org updates: http://kde-apps.org/content/show.php/KToshiba?content=18621
Yes, thanks, it will give me a go-by. I use kde3: http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_13.1/ I must be missing a package. This has always just worked. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday 14 of July 2014 20:52:39 David C. Rankin wrote:
Testing acpi_listen:
$ acpi_listen video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K ^\Quit
Hmm. So the keystrokes are seen with acpid running, but it has no effect on the brightness. So it looks like we need to create hooks or a config for the events. But where? /etc/acpi/events?
It depends on the desktop environment. On KDE 4.13.2, System Settings/Shortcuts and Gestures/Global Keyboard Shortcuts/KDE Daemon/Decrease or Increase Screen Brightness allows you to set the keys. -- Regards, Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/15/2014 05:28 AM, auxsvr@gmail.com wrote:
On Monday 14 of July 2014 20:52:39 David C. Rankin wrote:
Testing acpi_listen:
$ acpi_listen video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K ^\Quit
Hmm. So the keystrokes are seen with acpid running, but it has no effect on the brightness. So it looks like we need to create hooks or a config for the events. But where? /etc/acpi/events?
It depends on the desktop environment. On KDE 4.13.2, System Settings/Shortcuts and Gestures/Global Keyboard Shortcuts/KDE Daemon/Decrease or Increase Screen Brightness allows you to set the keys.
Guys, The problem here seems to be 13.1 itself. I ran acpi to get a status: # acpi -V Battery 0: Unknown, 100% Battery 0: design capacity 4000 mAh, last full capacity 4000 mAh = 100% Adapter 0: on-line Cooling 0: LCD 0 of 7 ^^^^^^^^^^^^^^^^^^^^^^ Cooling 1: Processor 0 of 3 Cooling 2: Processor 0 of 10 (which knocked network manager offline and my wireless??) Here is the issue: Cooling 0: LCD 0 of 7 WTF?? Cooling? then LCD 0 of 7?? It looks like the LCD brightness function is FUBAR in 13.1 for my Toshiba. Cooling?? I don't even know what to make of this? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/16/2014 03:49 AM, David C. Rankin wrote:
On 07/15/2014 05:28 AM, auxsvr@gmail.com wrote:
On Monday 14 of July 2014 20:52:39 David C. Rankin wrote:
Testing acpi_listen:
$ acpi_listen video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K ^\Quit
Hmm. So the keystrokes are seen with acpid running, but it has no effect on the brightness. So it looks like we need to create hooks or a config for the events. But where? /etc/acpi/events?
It depends on the desktop environment. On KDE 4.13.2, System Settings/Shortcuts and Gestures/Global Keyboard Shortcuts/KDE Daemon/Decrease or Increase Screen Brightness allows you to set the keys.
Guys,
The problem here seems to be 13.1 itself. I ran acpi to get a status:
# acpi -V Battery 0: Unknown, 100% Battery 0: design capacity 4000 mAh, last full capacity 4000 mAh = 100% Adapter 0: on-line Cooling 0: LCD 0 of 7 ^^^^^^^^^^^^^^^^^^^^^^ Cooling 1: Processor 0 of 3 Cooling 2: Processor 0 of 10
(which knocked network manager offline and my wireless??)
Here is the issue:
Cooling 0: LCD 0 of 7
WTF?? Cooling? then LCD 0 of 7??
It looks like the LCD brightness function is FUBAR in 13.1 for my Toshiba. Cooling??
I don't even know what to make of this?
I also think 13.1 is looking at the wrong brightness. The *current brightness* is 7, not zero. Recall, I show 2 brightness interfaces under /sys/class/backlight: # cat /sys/class/backlight/acpi_video0/brightness 7 # cat /sys/class/backlight/radeon_bl0/brightness 0 So it looks like acpi reports the wrong one, and who knows what it is attempting to set. The values never change in either when I use the function keys. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 16 of July 2014 04:03:58 David C. Rankin wrote:
Here is the issue:
Cooling 0: LCD 0 of 7
WTF?? Cooling? then LCD 0 of 7??
It looks like the LCD brightness function is FUBAR in 13.1 for my Toshiba. Cooling??
I also think 13.1 is looking at the wrong brightness. The *current brightness* is 7, not zero. Recall, I show 2 brightness interfaces under /sys/class/backlight:
# cat /sys/class/backlight/acpi_video0/brightness 7 # cat /sys/class/backlight/radeon_bl0/brightness 0
So it looks like acpi reports the wrong one, and who knows what it is attempting to set. The values never change in either when I use the function keys.
On my computer, the brightness keys do not work outside X. In your case, both the kernel interface to set the brightness and the keys work, therefore it is the job of the desktop environment to change the brightness on key press, unless you configure some daemon to do so independently. -- Regards, Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/16/2014 04:15 AM, auxsvr@gmail.com wrote:
On Wednesday 16 of July 2014 04:03:58 David C. Rankin wrote:
Here is the issue:
Cooling 0: LCD 0 of 7
WTF?? Cooling? then LCD 0 of 7??
It looks like the LCD brightness function is FUBAR in 13.1 for my Toshiba. Cooling??
I also think 13.1 is looking at the wrong brightness. The *current brightness* is 7, not zero. Recall, I show 2 brightness interfaces under /sys/class/backlight:
# cat /sys/class/backlight/acpi_video0/brightness 7 # cat /sys/class/backlight/radeon_bl0/brightness 0
So it looks like acpi reports the wrong one, and who knows what it is attempting to set. The values never change in either when I use the function keys.
On my computer, the brightness keys do not work outside X. In your case, both the kernel interface to set the brightness and the keys work, therefore it is the job of the desktop environment to change the brightness on key press, unless you configure some daemon to do so independently.
I think the problem is 13.1 does not have: xorg-x11-driver-video-radeonhd-1.3.0_20100512_80ba041-44.2.x86_64 There is no radeonhd driver to be found in the standard repos? In 11.4 the following were installed: xorg-x11-driver-input-7.6-144.1.x86_64 xorg-x11-driver-video-7.6-262.1.x86_64 xorg-x11-driver-video-intel-legacy-2.9.1-32.1.x86_64 xorg-x11-driver-video-nouveau-0.0.16_20110720_b806e3f-31.2.x86_64 xorg-x11-driver-video-radeonhd-1.3.0_20100512_80ba041-44.2.x86_64 The Archlinux wiki seems to have sorted out several approaches: https://wiki.archlinux.org/index.php/Backlight Since acpi works fine on my box, it looks like I can specify a custom Devices section in 50-device.conf to try and address the problem. Why is there no radeonhd driver for 13.1? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/16/2014 04:03 AM, David C. Rankin wrote:
On 07/16/2014 03:49 AM, David C. Rankin wrote:
On 07/15/2014 05:28 AM, auxsvr@gmail.com wrote:
On Monday 14 of July 2014 20:52:39 David C. Rankin wrote:
Testing acpi_listen:
$ acpi_listen video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K ^\Quit
Hmm. So the keystrokes are seen with acpid running, but it has no effect on the brightness. So it looks like we need to create hooks or a config for the events. But where? /etc/acpi/events?
It depends on the desktop environment. On KDE 4.13.2, System Settings/Shortcuts and Gestures/Global Keyboard Shortcuts/KDE Daemon/Decrease or Increase Screen Brightness allows you to set the keys.
Guys,
The problem here seems to be 13.1 itself. I ran acpi to get a status:
# acpi -V Battery 0: Unknown, 100% Battery 0: design capacity 4000 mAh, last full capacity 4000 mAh = 100% Adapter 0: on-line Cooling 0: LCD 0 of 7 ^^^^^^^^^^^^^^^^^^^^^^ Cooling 1: Processor 0 of 3 Cooling 2: Processor 0 of 10
(which knocked network manager offline and my wireless??)
Here is the issue:
Cooling 0: LCD 0 of 7
WTF?? Cooling? then LCD 0 of 7??
It looks like the LCD brightness function is FUBAR in 13.1 for my Toshiba. Cooling??
I don't even know what to make of this?
I also think 13.1 is looking at the wrong brightness. The *current brightness* is 7, not zero. Recall, I show 2 brightness interfaces under /sys/class/backlight:
# cat /sys/class/backlight/acpi_video0/brightness 7 # cat /sys/class/backlight/radeon_bl0/brightness 0
So it looks like acpi reports the wrong one, and who knows what it is attempting to set. The values never change in either when I use the function keys.
I'm beginning to think this is a grub2 / kernel issue. I have found several issues recommending adding the following to the kernel command line: acpi_backlight=vendor http://www.refreshit.info/2012/08/solved-brightness-increase-and-decrease.ht... In 13.1, can I still just press 'e' and edit the grub2 boot line? I'll try. If there is another way, let me know. Thanks. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/16/2014 04:27 AM, David C. Rankin wrote:
On 07/16/2014 04:03 AM, David C. Rankin wrote:
On 07/16/2014 03:49 AM, David C. Rankin wrote:
On 07/15/2014 05:28 AM, auxsvr@gmail.com wrote:
On Monday 14 of July 2014 20:52:39 David C. Rankin wrote:
Testing acpi_listen:
$ acpi_listen video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessdown BRTDN 00000087 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K video/brightnessup BRTUP 00000086 00000000 K ^\Quit
Hmm. So the keystrokes are seen with acpid running, but it has no effect on the brightness. So it looks like we need to create hooks or a config for the events. But where? /etc/acpi/events?
It depends on the desktop environment. On KDE 4.13.2, System Settings/Shortcuts and Gestures/Global Keyboard Shortcuts/KDE Daemon/Decrease or Increase Screen Brightness allows you to set the keys.
Guys,
The problem here seems to be 13.1 itself. I ran acpi to get a status:
# acpi -V Battery 0: Unknown, 100% Battery 0: design capacity 4000 mAh, last full capacity 4000 mAh = 100% Adapter 0: on-line Cooling 0: LCD 0 of 7 ^^^^^^^^^^^^^^^^^^^^^^ Cooling 1: Processor 0 of 3 Cooling 2: Processor 0 of 10
(which knocked network manager offline and my wireless??)
Here is the issue:
Cooling 0: LCD 0 of 7
WTF?? Cooling? then LCD 0 of 7??
It looks like the LCD brightness function is FUBAR in 13.1 for my Toshiba. Cooling??
I don't even know what to make of this?
I also think 13.1 is looking at the wrong brightness. The *current brightness* is 7, not zero. Recall, I show 2 brightness interfaces under /sys/class/backlight:
# cat /sys/class/backlight/acpi_video0/brightness 7 # cat /sys/class/backlight/radeon_bl0/brightness 0
So it looks like acpi reports the wrong one, and who knows what it is attempting to set. The values never change in either when I use the function keys.
I'm beginning to think this is a grub2 / kernel issue. I have found several issues recommending adding the following to the kernel command line:
acpi_backlight=vendor
http://www.refreshit.info/2012/08/solved-brightness-increase-and-decrease.ht...
In 13.1, can I still just press 'e' and edit the grub2 boot line? I'll try. If there is another way, let me know. Thanks.
I tried acpi_backlight=vendor, but all it did was cause /sys/class/backlight/acpi_video0 to disappear, leaving only the radeon_bl0 entry. I tried enabling backlight with: systemctl start systemd-backlight@radeon_bl0.service which did start fine, but to no avail. The function keys still did not work and attempting to manually set /sys/class/backlight/radeon_bl0/brightness caused all kinds of hell to break loose with my display. (requiring typing in the blind 'sudo shutdown -r now' and praying) I have put my 11.4 drive back in the laptop and compared acpi_listen values. The values returned are different. Under 11.4 I get: # acpi_listen video LCD 00000087 00000000 video LCD 00000087 00000000 video LCD 00000087 00000000 video LCD 00000086 00000000 video LCD 00000086 00000000 video LCD 00000086 00000000 The numerical values are the same, but the labels are completely different. There is just something broken in 13.1. I have exhausted my bag of tricks. I opened the following bug to fix the issue: https://bugzilla.novell.com/show_bug.cgi?id=887629 -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/16/2014 04:32 PM, David C. Rankin wrote:
I tried acpi_backlight=vendor, but all it did was cause /sys/class/backlight/acpi_video0 to disappear, leaving only the radeon_bl0 entry. I tried enabling backlight with:
systemctl start systemd-backlight@radeon_bl0.service
which did start fine, but to no avail. The function keys still did not work and attempting to manually set /sys/class/backlight/radeon_bl0/brightness caused all kinds of hell to break loose with my display. (requiring typing in the blind 'sudo shutdown -r now' and praying)
I have put my 11.4 drive back in the laptop and compared acpi_listen values. The values returned are different. Under 11.4 I get:
# acpi_listen video LCD 00000087 00000000 video LCD 00000087 00000000 video LCD 00000087 00000000 video LCD 00000086 00000000 video LCD 00000086 00000000 video LCD 00000086 00000000
The numerical values are the same, but the labels are completely different. There is just something broken in 13.1. I have exhausted my bag of tricks. I opened the following bug to fix the issue:
All, I really don't believe this. It seems the problem in 13.1 is that the "radeon X11 driver seems not providing xrandr backlight property." (see: https://bugzilla.novell.com/show_bug.cgi?id=887629#c15) I need the brain-trust's help is determining: (1) whether this can be re-enable with a build option to the existing radeon X11 driver; or (2) if not, whether anyone is building alternate X11 drivers (i.e. the old radeonHD driver) for 13.1. Moreover, what source is even used anymore? I've searched OBS for radeon and all I get are 'radeon-profile' and 'libdrm-radeon1'?? Where is the driver and who is the current maintainer? (the radeon driver has now entered ... the twilight zone...) Apparently the 'ati-dri' source package is what provides the Mesa drivers for AMD/ATI Radeon, and I can't even find that in the repositories. The closest I find is libvdpau_radeonsi and that apparently just "contains the VDPAU state tracker for radeonsi" in order to tell which driver is loaded. So I am in need of help to identify what package to look at and who to talk to regarding this problem. Any help will be greatly appreciated. Thanks. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/28/2014 02:53 PM, David C. Rankin wrote:
I really don't believe this. It seems the problem in 13.1 is that the "radeon X11 driver seems not providing xrandr backlight property." (see: https://bugzilla.novell.com/show_bug.cgi?id=887629#c15)
As a workaround, I wrote a script to incrementally increase/decrease the backlight. It will work in any desktop that allows assinging shortcut keys to an application. In KDE3, I simply created 2 menu entries 'Backlight Control Increase' and assigned the shortcut 'screenbrightness.sh -i' to the XF86MonBrightnessUp key and a similar entry 'Backlight Control Decrease' and assigned the shortcut 'screenbrightness.sh -d' to the XF86MonBrightnessDown key. (uncheck Enable Launch Feedback on each entry) It works fine for backlight control in KDE3, but it is frustrating to have to come up with workarounds on a desktop-by-desktop basis. Hopefully this bug will get fixed. It appears this is a kenel bug: https://bugzilla.kernel.org/show_bug.cgi?id=55311 screenbrightness.sh attached if anyone else is in the same situation with 13.1... -- David C. Rankin, J.D.,P.E.
participants (5)
-
Alvin Beach -
auxsvr＠gmail.com -
David C. Rankin -
Malcolm -
Peter