You can have a look at some stuff in /proc
and /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. /proc
and /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":
»cat lcd
brightness: 5
brightness_levels: 8
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/
actual_brightness
bl_power
brightness
device
max_brightness
power
subsystem
type
uevent
Some of those are directories. Now:
»cd acpi_video0/
»cat max_brightness
7
This does correspond to the "brightness_levels" from proc, since 0-7 is 8 levels.
»cat brightness
5
»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 sysctl
, see 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.