You can have a look at some stuff in
/sys and see what happens; the brightness widget or whatever in your DE (you did not say which one) uses some interface to something there.
/sys do not exist on disk; the files they contain are special interfaces to the kernel. Many of the files can be written to to control various things.
For example: I'm using a toshiba satellite and in there is a "toshiba" directory in
/proc/acpi. In that directory there is a file "lcd":
You can't write to this file, however. More useful that way are some directories in
/sys/class/backlight -- I have "acpi_video0", "intel_backlight", and "toshiba" again. However, this toshiba directory contains different stuff. Having already fooled around with this, I know that the relevant stuff in my case is actually in "acpi_video0":
»ls -1 acpi_video0/
Some of those are directories. Now:
This does correspond to the "brightness_levels" from proc, since 0-7 is 8 levels.
»echo 2 > brightness
If you are not root, the echo will fail with "Permission denied". Since I was
root at that point, my screen suddenly got a lot dimmer.
The widget on my KDE desktop that pops up when I use the keyboard dimmer goes from 0-100 usually in increments of 10 or 20% -- or sometimes doesn't give a percent, or occasionally gives "52%" or something -- but in empirical reality it is always the same 7 steps from 0% to 100%. With KDE there's some brightness stuff in the GUI Systems Settings under "Power Management" but again, it all relates to the same thing.
You can also access/browse/manipulate the values in
/sys using the command
man sysctl. Which method is simpler probably depends on how you use the command line; I use an orthodox filebrowser (mc) which makes a difference, since I don't actually have to cd/ls/cat etc.
So have a look at that stuff and see what happens. Keep in mind that since hardware manufacturers generally do not provide linux drivers, someone has to develop them and often without being paid (meaning, in their spare time). Furthermore, those manufacturers are often hostile to requests for information which might be helpful in creating such drivers (I've been there), making the process a pain in the ass. Net result: not all the drivers are 100% functional (which is not the same as defective -- they work, they just don't work to do everything). Que sera, sera.