I don't know if this fixes it for everyone but changing the line GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor" in /etc/default/grub and then running update-grub fixed it for me.

I followed your instructions regarding the changes in the GRUB file and it worked for me too and now I'm able to adjust the brightness of the screen!
Thanks a lot and keep up with the good work!!

The issue doesn't seem to be resolved... After updating the brightness keys didn't work anymore, the fix still works but, whenever the GRUB file is updated you've got to 'get your hands dirty' again. So would anybody be so kind to de-"Resolved" it? It isn't high priority of course, but it isn't resolved. Does it hurt to add it into the GRUB file by default? If it doesn't, that might be a (temporary) solution. :)

@ElecProg I closed the issue because the original author said it was resolved. You provided no indication that it was a persistent issue for you.

As for the changes persisting. My guess is you shouldn't be editing /etc/default/grub and that there is a better way to make changes to grub. @ikey would know better than me.

@DataDrake,

I seem to have expressed myself a bit too harshly. The issue is resolved for the original author, however, if I understand correctly, one of the main goals for Solus is to make it 'run out of the box', this also means that something like display brightness should work without having to change system files. Because of that I was surprised to see it being labeled as resolved. There are, indeed, more important issues, but I think this is still something that should be fixed at one point or the other.

With the utmost respect for your brilliant work on this wonderful operating system,
Evert 'ElecProg' Provoost

@ElecProg No, if anything I apologize for coming across as upset. I was not at all, just explaining me reasoning for originally closing the task. I was unaware that package updates would scrub the changes. You gave a valid reason for re-opening the task. When you ended your last message with " fixed it for me", I made the assumption this was resolved for everyone involved, that's all.

@DataDrake I'm glad we're on the same page then :)

Found this solution on the forum to solve a similar problem I was having, which was to install xbacklight:

sudo eopkg it xbacklight

It worked for me. Don't know if it will help you. Thought I would share just in case.

Original post: https://solus-project.com/forums/viewtopic.php?f=9&t=2314&p=15040#p15040

With budgie 11 and eventual shift to wayland, xbacklight won't work anymore. I found acpilight for drop-in replacement for xbacklight. I have yet to test it, but if there is no permanent fix until budgie 11 is released, this might provide a temp fix then.

With the most recent update the changing of the GRUB file doesn't work, however while booting there are complaints concerning GRUB so it might be down to that?

EDIT: Probably not, since it's grup giving errors, not grub.

Somehow, this fixed itself on me. Happened sometime before clr-boot-manager, so can't pin on that. I'm sorry I cannot say when, exactly, because I set new keyboard shortcuts for xbacklight and used them. Tried default brightness keys by accident couple of weeks ago and they worked. This happened to anyone?

Unfortunately the default buttons didn't magically start working for me... However xbacklight now does so adding custom shortcuts for xbacklight, is a workable solution (binding the commands to the default buttons doesn't work however...)

One advantage of xbacklight is extremely fine tuning. My laptop display supports over 700 steps, and even with percentage shortcuts, I could go as low as 1%, perfect for late night streams...

Don't know whether this can be a "general solution", but on my rig adding:

acpi_osi=Linux

to the GRUB command did the trick ?

Definitely would be interesting to see if this is a general fix. Or at least some hardware detection we can do in the installer..
What's the common hardware for all of you ?

Never had any issue setting the brightness on my laptop.

In T863#62820, @ikey wrote:

What's the common hardware for all of you ?

My laptop is a Dell Vostro 3700 with Optimus-(un)powered graphics. Here's an 'inxi' extract, in case it's useful:

Machine:   System: Dell (portable) product: Vostro 3700 v: A12
           Mobo: Dell model: 07VWR8 v: A12 BIOS: Dell v: A12 date: 04/08/2014
CPU:       Dual core Intel Core i5 M 460 (-HT-MCP-) cache: 3072 KB 
           clock speeds: max: 2528 MHz 1: 2261 MHz 2: 1197 MHz 3: 1197 MHz 4: 1197 MHz
Graphics:  Card: NVIDIA GT216 [GeForce GT 330M]
           Display Server: X.Org 1.18.4 driver: nvidia Resolution: 1600x900@60.08hz
           GLX Renderer: GeForce GT 330M/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 340.96

I'm running updated Solus Budgie, fwiw.

Let me know if you need different kind of info.

Is there a similar solution available for UEFI/goofiboot?

@deepakkapoor23 I don't have goofiboot but if the internet isn't lying the config file is here: /boot/efi/loader/entries/solus.conf. There should be a line starting with options and you can add acpi_osi=Linux there, no guaranteed succes of course :)

I recently played a bit with some other distros and it's a rather common problem, however Deepin seemed to have this working out of the box so maybe it's worth to look there for a solution? The common hardware seems to be that there are two gpus (an embedded one and a dedicated one) so I'm guessing that the command to change brightness doesn't reach the destination.

I tested adding acpi_osi=Linux and acpi_backlight=vendor separately and combined to GRUB, neither worked.

For those interested: acpi_osi=Linux makes the kernel communicate to the hardware that it's Linux instead of Windows (if my sources are correct Linux claims to be Windows by default but it could be that this has been changed) and acpi_backlight=vendor makes the kernel prefer the vendor driver over the generic driver for the backlight.

When I have some time I'm going to take a look at the changelog of the kernel concerning acpi because acip_backlight=vendor used to work before a kernel update.

(This is a rewrite of my earlier comment from before testing the changes to the GRUB file.)

Further tried to add acpi_backlight=video and acpi_backlight=native, still no success. xbacklight also stopped working. Just wondering, how does Solus actually try to control brightness?

I've been experiencing this / a similar problem with a Lenovo ThinkPad P50.

• The function keys for display brightness work as expected when booting into the Solus Budgie 3 live image, also work fine on clean install.
• After updating the system with "eopkg up" the keys stopped working. The laptop has an Intel+Nvidia combination but I've got it configured to only use the Nvidia graphics in the BIOS.
• Journalctl shows the following errors when using the function keys:

gsd-media-keys[1017]: Failed to set new screen percentage: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._gsd_5fpower_5fmanager_5ferror.Code0: Screen backlight not available

• xbacklight -set does work still