[solved] Screen brightness persistance

[Member blur13]

Hi!

I have an ASUS eee pc from 2012. Every time I start the computer the screen is at the dimmest setting. Every time the computer wakes up from sleep mode the screen is at the brightest setting. Is there any way to get some persistence on the screen brightness?

I’ve looked in the /sys/class/backlight/acpi_video0 directory and the files “actual_brightness” and “brightness” both contain the same value between 0-10 and changes when I change the brightness. I can’t change the value in “actual_brightness” using sudo but I can change the value in “brightness” using sudo, and there is an immediate change in the brightness. So if there is no direct solution in some setting I don’t know about, perhaps I could create a script that stores the current value of “brightness” before sleep/shutdown and then echoes that value into “brightness” on resume/startup? My knowledge regarding shell scripts is unfortunately pretty limited.

• This topic was modified 1 year, 3 months ago by anticapitalista. Reason: solved

[Member Xecure]

Helpful

Up

0

::

What does the backlight-brightness app show? What version of antiX are you running? Do you have the brightness service enabled or disabled?

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member blur13]

Helpful

Up

0

::

1) radeon_bl0
2) 19.4
3) I’m not sure, I cant find anything that fits the bill when looking through the processes in htop

I did an online search for “brightness service debian” and found a package called brightnessctl that also pulled in a dependency package. Installing that package has somehow created persistence between sleep session, and starts up the screen at full brightness when booting up. I’m guessing it has something to do with the following:

From their github:

Permissions
Modifying brightness requires write permissions for device files or systemd support. brightnessctl accomplishes this (without using sudo/su/etc.) by either of the following means: 1. installing relevant udev rules to add permissions to backlight class devices for users in video and leds for users in input. (done by default)

So thanks for the help Xecure!!

[Member Xecure]

Helpful

Up

0

::

backlight-brightness comes with a service named “brightness” which usually manages the loading and saving of the brightness parameter.
sudo servive brightness start
loads the last used brightness, and should start at boot-time with the other system settings.
sudo service brightness stop
saves the brightness levels at shutdown so that they can be loaded on next boot.
see if it starts up properly using the service startup viewer program (can be launched from the control centre).

I have little experience using it outside of intel based graphics, so I don’t know if it has a compatibility issue with radeon graphics. Maybe the creator can tell us.

I did have trouble with the brightness not working on antix-21beta with runit, but that was solved by the developers.

If brightnessctl is working for you, then there is no need to explore any further. It would be interesting to learn why the brightness service didn’t save the brightness value properly for your computer, but I wouldn’t know how to propose a fix to it anyway.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member blur13]

Helpful

Up

0

::

Thats interesting! I looked up “brightness” in the service startup viewer program and there is only a checkbox ticked at the far right, under “S” (for shutdown?). Which run levels should I enable it for? 2, 3, 4, 5? I dont recall ever turning this off, although I might have been a bit overzealous in trimming away things I regarded as unnecessary or “bloat”..

[Member Xecure]

Helpful

Up

0

::

S is start. It should also have options to stop the service in 0 and 6.
You can restore it to its defaults with
sudo update-rc.d brightness defaults

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member blur13]

Helpful

Up

0

::

Been experimenting with the “brightness” service a bit now. Running sudo update-rc.d brightness defaults either didnt do anything or the default is a checkmark under S. I tried manually setting it to also run at 0 and 6. That seems to trigger max brightness at startup and resume (from sleep), regardless of what the brightness was before. Tried enabling the service at every run level, with the same results. Disabled the service completely and back to using brightnessctl. It has an option of saving the current brightness. Its not perfect but better than nothing. The search continues….

thanks so much for your time Xecure!

[Member blur13]

Helpful

Up

0

::

To follow up on the above. I have been experimenting some more, since this issue really bugs me. I have three relevant folders in /sys/class/backlight/, namely:

/sys/class/backlight/acpi_video0
/sys/class/backlight/acpi_video1
/sys/class/backlight/radeon_bl0

Like I said before, changing the brightness with the brightness keys on my laptop does change the brightness, but whenever the screen shuts off due to reboot, suspend, or just screen blanking, the brightness is at the max setting again. I’ve since discovered that changing the brightness setting in acpi_video0 does change the brightness, but it resets when the screen is off. The antiX “Backlight Brightness” app changes the radeon_bl0 settings. Changing the brightness this way DOES create persistence. So it seems that the brightness keys on the laptop are changing the settings in acpi_video0, instead of radeon_bl0. The app brightnessctl I described above allows changing the brightness from the terminal, and I can specify the device used. Ie “brightnessctl -dradeon_bl0 s +10%” increases the relevant brightness by 10%, and its persistent, and the change is reflected in the “Backlight Brightness” app. Therefore I thought I would remap the brightness keys on the laptop to two shell scripts running the brightnessctl commands. Using xev I found that the keys are called XF86BrightnessUp and XF86BrightnessDown. I edited the /home/$USER/.icewm/keys and added the following lines

key “XF86BrightnessUp” brightup.sh
key “XF86BrightnessDown” brightdown.sh

with the shell scripts being the relevant brightnessctl command.

This works. With the caveat that the old keymapping still seems to be active. It seems that when I press the brightness down key, that there are two seperate “brightness down” actions. I assume the .icewm/keys takes preference, but the key in question seems to have more than one name. I used XF86BrightnessUp because thats in line with the name of other function keys already in the file. Is there any other place in antiX/debain where function keys are defined?

[Member ModdIt]

Helpful

Up

0

::

I only use ICEWM, that has a .keys file in home, you may be able to map your brightness keys in that. Maybe
BobC will see this, he knows way more on ICEWM and key configuration.

[Member blur13]

Helpful

Up

0

::

Reviving this thread to post the solution, for completeness sake. Maybe an admin can mark this post as [SOLVED]

In antiX 19.x, add the following line in the .desktop-session/startup to have the screen start at 50% brightness

backlight-brightness -s 50 &

Credit to antixbanget and dave for solving it.

[Author]

Posts