openSUSE / openSUSEway

dotfiles for Sway on openSUSE
MIT License
82 stars 17 forks source link

make brightness control exponential #112

Open nova-r opened 1 year ago

nova-r commented 1 year ago

As brightness is perceived exponentially and not linearly, it would be more intuitive for brightness control via hotkeys to follow an exponential curve as well. brightnessctl supports this already by setting the -e flag.

FilippoBonazziSUSE commented 1 year ago

Nice proposal. However this has 2 disadvantages:

  1. The displayed brightness percentage will then follow what looks to the user like an "irregular" series, i.e. it will go
    100%
    81%
    66%
    52%
    41%
    32%
    24%
    18%
    ...
  2. Consequently, it kind of gets weird at low brightness values. Once it goes to low values (e.g. 1 or 0) the number will not change but brightness will.

IMHO we would need a mechanism to re-map the read-out value from an exponential scale to a linear one again as well.

nova-r commented 1 year ago

I've added the changes as suggested. It now remaps the exponential scale back to linear for wob see PR #113

FilippoBonazziSUSE commented 1 year ago

This is really a brilliant change! Pardon the pun.

I would be in favour of this. Since this is literally a very visible change, I'm going to ask a couple more people for review. @denisok @jubalh thoughts?

FilippoBonazziSUSE commented 1 year ago

Although, on further testing, I have to admit I am not sure I like how this behaves with brightness below e.g. 30% (exponential scaled to linear). Like, once you go below 30% almost nothing changes in brightness, so it feels like we're wasting a piece of the scale at the low end and compressing perhaps meaningful differences at the high end.

nova-r commented 1 year ago

Thanks for the feedback! I also have noticed the weird behavior at low percentages. I'll try to correct this behavior soon :)

nova-r commented 1 year ago

I've written the conversion of the exponential curve back to linear based on the calculation that brightnessctl uses when passing the -e flag using the default value of 4: https://github.com/Hummer12007/brightnessctl/blob/master/brightnessctl.c#L344

I've tried different programs to do the calculations, but all of them have the issue at low percentages. Moving away from the default exponent to a custom one that fits our use case, may resolve the problem

denisok commented 1 year ago

I agree with @FilippoBonazziSUSE . Currently (with current changes) it works maybe better on high levels of brightness but it degrades when you get lower and also wob doesn't show it right.