Support fractional values

[Hummer12007]

Supersedes #51
Fixes #50

first one adds parsing fractional percentages, unconditionally, and alters the calculations to account for it

second one adds --frac to print percentages as floats. I'm not sure if it warrants a short option (-f and -F may be useful for other stuff).

I'll sit on it for some time and think about it.

If anyone is interested @bbarenblat @Atemu, please test it (there might be some regressions in calculations).

[Hummer12007]

@andeston please check out if it fixes #118 for you

[xdbob]

nitpick: I would either convert all the float handling to double or use strtof

[Hummer12007]

I conciously made it double, in case some display maker decides that their brightness scale goes to higher than 16.777.216 (it's 15360 on my laptop, which freaked me out when I noticed it first)

[xdbob]

Remove the -V part

[Hummer12007]

Nice catch!

[xdbob]

Looking at #51 (comment) wouldn't the --frac incompatible with the -m option ? should this be documented or handled in some way ?

[Hummer12007]

Nah, I checked, we don't setlocale, so it always uses the dot

[andeston]

Percentage changes are floating point for a reason.

Can you elaborate, @Hummer12007?

#118 is not fixed by this.

I don't mean to come off as dismissive here, but are fractional percentages actually useful? It feels like more trouble than it's worth. At least on my system, a +/-1% change is already almost imperceptible.

With such a low max brightness, setting a fractional brightness isn't accurate anyway. If precision is truly what a user needs, setting the brightness in device units is always going to be as precise and accurate as possible.

$ ./brightnessctl -m --frac s 50%
amdgpu_bl1,backlight,128,50.2%,255
$ ./brightnessctl -m --frac s 10%+
amdgpu_bl1,backlight,154,60.39%,255
$ ./brightnessctl -m --frac s 10%-
amdgpu_bl1,backlight,129,50.59%,255
$ ./brightnessctl -m --frac s 10%+
amdgpu_bl1,backlight,155,60.78%,255
$ ./brightnessctl -m --frac s 10%-
amdgpu_bl1,backlight,130,50.98%,255
$ ./brightnessctl -m --frac s 10%+
amdgpu_bl1,backlight,156,61.18%,255
$ ./brightnessctl -m --frac s 10%-
amdgpu_bl1,backlight,131,51.37%,255
$ ./brightnessctl -m --frac s 10%+
amdgpu_bl1,backlight,157,61.57%,255
$ ./brightnessctl -m --frac s 10%-
amdgpu_bl1,backlight,132,51.76%,255
$ ./brightnessctl -m --frac s 10%+
amdgpu_bl1,backlight,158,61.96%,255
$ ./brightnessctl -m --frac s 10%-
amdgpu_bl1,backlight,133,52.16%,255
$ ./brightnessctl -m --frac s 10%+
amdgpu_bl1,backlight,159,62.35%,255
$ ./brightnessctl -m --frac s 10%-
amdgpu_bl1,backlight,134,52.55%,255
$ ./brightnessctl -m --frac s 10%+
amdgpu_bl1,backlight,160,62.75%,255
$ ./brightnessctl -m --frac s 10%-
amdgpu_bl1,backlight,135,52.94%,255

[Hummer12007]

I don't really remember tbh, but 7b607b3 fixed a bug, and was more correct than the previous behavior. Most likely in the case with an exponent set.
I'll try to play around a bit more with the code later.
0-255 is a really nice pathological case though.

Something along the following lines may fix your use case:
if the delta is a percentage, and the current value corresponds to the result of trying to set an integer percentage, then round down the percentage; which would obviously break if the exponent gets changed but w/e.

[Hummer12007]

@andeston does this work for you?

[andeston]

@Hummer12007 a5a9a95 didn't work. Does #128 work for you?