The backlight of an lcd device and the leds around an eink device are the same from the PoV of the OS.
For instance, on my linux laptop "brightnessctl" returns
Code:
Device 'intel_backlight' of class 'backlight':
Current brightness: 100 (53%)
Max brightness: 187
and I can set the desired brightness from 0 (off) to the max brightness specified above.
In the same vein, on a eink device with frontlight leds I can set the brightness from the minimum to the maximum.
In both cases which determines the minimum and the maximum are device drivers. In this case I can retrieve the info that's exported in sysfs with "udevadm info --attribute-walk --path=/sys/class/backlight/intel_backlight"
the result, as you can see, returns the same:
Code:
...
looking at device '/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight':
KERNEL=="intel_backlight"
SUBSYSTEM=="backlight"
DRIVER==""
ATTR{actual_brightness}=="100"
ATTR{bl_power}=="0"
ATTR{brightness}=="100"
ATTR{max_brightness}=="187"
ATTR{power/control}=="auto"
ATTR{power/runtime_active_time}=="0"
ATTR{power/runtime_status}=="unsupported"
ATTR{power/runtime_suspended_time}=="0"
ATTR{scale}=="unknown"
ATTR{type}=="raw"
...
So, to sum up:
Kernel drivers provide our (and stock) source of truth.
It could be possible to tweak specific kernel drivers to provide more granularity in case the minimum/maximum exposed by the driver don't match the (safe) minimum/maximum the hardware is capable. The same happens with the steps between n and n+/-1 brightness.
Nobody sensible enough is going to play with this on a embedded device like the Kindle.