Page MenuHomeSolus

Closed due to inactivityPublic


My laptop has problems with brightness control, as in brightness doesn't change with brightness keys automatically detected during install. I have yet to find why exactly this happens, but I have a stopgap in the form of "xbacklight".

xbacklight is a RandR based backlight control application, included by default in Solus stable repos. It works perfectly for changing backlight through CLI, and more efficiently through custom keyboard shortcuts.

However, backlight functionality was moved into kernel's ACPI interface, making this slightly unnecessary. Also, Because it goes through RandR, it is dependent on X.

acpilight acts as drop in replacement for xbacklight command, while acting directly through kernel's ACPI interface, making it workable even without X. This shall come in handy with eventual shift to wayland (we all know its a when rather than if).

I have no idea how many people will be using this, but my Acer 5755-9401 has had this issue with every single distro including Ubuntu/Mint, Fedora, Arch/Antergos and Solus.

Here is the homepage for acpilight, where further information can be found, along with source code:

Event Timeline

whatever updated the task description. (Show Details)
whatever updated the task description. (Show Details)
DataDrake removed whatever as the assignee of this task.Apr 19 2017, 11:47 AM

It's very easy to package (a simple python script an udev rules).
It was released in February so if it's accepted, I can do it.

DataDrake triaged this task as Wishlist priority.Jul 12 2018, 2:59 PM
DataDrake moved this task from Backlog to Accepted For Inclusion on the Package Requests board.

I got this packaged and tested to control both the keyboard & screen backlight on my dell xps 15, but before I submit the patch, I want to make sure that it is clear that the aim of this application is to replace xbacklight.

@kyrios123 I've been trying out swaywm, which is wayland only, and brightness control is one of the last pet-peeves. Can we simply show a warning before installing acpilight that it would replace xbacklight?

@kyrios123 I've been trying out swaywm, which is wayland only, and brightness control is one of the last pet-peeves. Can we simply show a warning before installing acpilight that it would replace xbacklight?

Nope, eopkg doesn't handle conflicts.
And since acpilight claims to be backward compatible with xbacklightthere is no reason to keep both anyway.
Let's wait for a decision.

Hol' up. If acpilight is going to remove xbacklight, I believe it does ask for confirmation from user for so. And since user shall be installing this package manually in 100% of cases, we can say with sufficient confidence that they know what they're doing. Even then, if acpilight is enough to do xbacklight's work, there shouldn't be any problem just going forward and removing xbacklight.

I feel in this case that backwards compatible means it uses the exact same commands and user options where the backend works completely differently. I imagine this only works where there's no acpi issues with the device, meaning it doesn't fill the hole that xbacklight does (it works on X when acpi does not).

There seems to be 100 of these little apps now, perhaps it needs to settle on 1 or 2 of the better, more well supported ones since they are all basic and effectively doing the same thing.

crom5 added a subscriber: crom5.Oct 4 2018, 1:03 PM

Hello, one year has passed since I reported at Nvidia Linux forum that on my notebook Asus G752VS (Nvidia GeForce GTX 1070) brightness control doesn't work - regardless if I try to change screen brightness with the slider within Pover options or by using keyboard FN keys //( I would like to kindly ask if there's any way I can somehow try acpilight? By the way, regarding this problem, I am also waiting for the arrival of X.Org server 1.20.1 into the Solus...

@crom5 you can try this package, then use sudo eopkg history -t to revert

crom5 added a comment.Oct 5 2018, 1:27 PM

This is my post on Nvidia Linux forum from 5 minutes ago:

//Thank you very much generix for your advice.
These are the 2 experiments that I performed after firstly uninstalling xbacklight:

I installed ( the package "acpilight"//

sudo eopkg install acpilight-1.1-1-1-x86_64.eopkg

Nothing changes, brightness control still doesn't work.
Then I followed the instructions from the "acpilight" webpage:
Setup an "udev" rule to allow users in the "video" group to set the display brightness. To do so, place a file in /etc/udev/rules.d/90-backlight.rules containing:

SUBSYSTEM=="backlight", ACTION=="add", \
  RUN+="/bin/chgrp video /sys/class/backlight/%k/brightness", \
  RUN+="/bin/chmod g+w /sys/class/backlight/%k/brightness"

Nothing changes, brightness control still doesn't work.
Before performing the second experiment, I uninstalled acpilight package and deleted its udev rule.

Here's the simple reason why I think that I don't have the suggested acpi daemon (acpid) installed in my Solus: Solus Development Portal: "acpid" - closed, wontfix:

I added a kernel boot parameter "nvidia.NVreg_EnableBacklightHandler=1" in this way://

$ sudo su
$ mkdir -p /etc/kernel
$ echo "nvidia.NVreg_EnableBacklightHandler=1" > /etc/kernel/cmdline
$ clr-boot-manager update
$ exit

//Magically, the brightness control finally works, both by using the slider within Pover options and by using the keyboard FN keys.
My question is: one year after Nvidia started experimenting with this option, when it will be proclaimed as a stable and in what way it will be applied (automatic job or it will still required user's manual intervention)?

Unfortunately, once again the new brightness setting isn't remembered after restart. Since Aaron Plattner said that remembering and restoring the backlight brightness on restart isn't the driver's job, I will ask Solus developers for help.//

Now when the brightness control on my laptop finally works as it should, I am curious if "missing" acpi daemon (acpid) can be the cause that the new brightness setting isn't remembered after restart?

DataDrake closed this task as Wontfix.Nov 17 2018, 2:24 PM
DataDrake added a subscriber: DataDrake.

As this task has been marked Needs Maintainer for a month with nobody having stepped up to become maintainer, in addition to providing an acceptable patch for inclusion, marking as WONTFIX. Feel free to re-open when a patch has been submitted via the proper processes.

DataDrake changed the task status from Wontfix to Frozen.Feb 21 2022, 8:29 AM