Creating a customized, more responsive e16 BrightnessDown key binding for very dark surroundings

Howtos Elive
1

I've noted it before:
Current keybindings in E16 (and Enlightenment for that matter) increment the screen-brightness by 10% of the maximum .... both "up" and "down".
For me at night that means my screen has the lowest setting of 10% (after that it's off, i.e 0%) which is still totally blinding in my ship's wheelhouse....I need it to go down to 1% or even less.

Now I've discovered that 'brightnessctl' as a command also has an option to set the brightness as an integer with the "s" flag and gets the current brightness value with 'brightnessctl g'.

Which made me change the settings of the .e16/bindings.cfg to what I need.
the current line that defines the brightness-down is:
KeyDown - XF86MonBrightnessDown exec sudo -n brightnessctl s 10%-

Which I changed to:

KeyDown - XF86MonBrightnessDown exec bash -c "sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`"

Which will halve the current value, thus creating an infinite lowering of the brightness were it not that 'bc' in it's simplest iteration only does integers (i.e whole numbers) which also means that below value "1" there'll be a zero (= backlight off).

I'd advise to keep the brightness-up setting at 10%+ because in general, when wanting a higher brightness, one will want to go up to about 100% as fast as possible....any increment below that, will feel extremely unresponsive.

2

HI!

Nice!
I'm too a 1% light screen user, both for night work & power saving...
Thank you!
:+1:

Salutations!

3

Glad it helped someone out :wink: I wasn't sure my use-case wasn't too peripheral but posted it anyway. :face_with_peeking_eye:

Just for the sake of ease:
If you keep the settings as I've explained, going down a step too far (to 0%) by accident .. you just need 3 clicks to be back at 1%.
0 -> 10% then 10->5 (1st click) 5-> 2 (2nd click) 2->1 (3rd click).
Believe me, when taking a ship down extremely dark rivers or canals .... you don't want to look at the screen but trust in muscle memory. :w00t:

Au prochaine

1 Like
5

I created a wrapper for the tool which will decrease/increase the value in different % steps depending of their brightness, this should solve the issue, can you try it @triantares ? if works good and is better than the previous mode i will replace the tool with this one:

6

Yeah, I thought (and tried) a similar script but found that that required too many steps to get brightness down (or up).
Especially if it only diminishes the integer by "1" after 1%, which in my case is integer "191" ..... that's a lot of steps down to "1" and looks & feels as if nothing is happening. :astonished:

I think halving the halving the value is more responsive.
So practically my conclusion:

Great scripting but doesn't remedy the issue better (on the contrary) than the relatively simple one-liner.

What I do think the one-liner (or any brightness script) needs is a short showing of the setting % on the screen after it's changed. Just a short fllash mid screen with "Brightness set to --%" text.

1 Like
7

the problem is that the values vary a lot between computers, it can be between 0 and 200 in some, between 0 and 10 in others, and even between 0 and 1 lol, that's why a script like this one that picks the step dynamically based on the percentage is a better option, the only issue is when the value is less than 2% as you can see on the script which changes to integer, these can be maybe 30 or 50 steps as you said, (probably only 20, which is not a big issue)

that's a task for the new E :slight_smile: in fact it has already an emodule for brightness, we don't need these advanced features on E16 or at least not worth to invest the time on it if we are moving to the new E

question: did you tried the tool ? it doesn't works well when pressing multiple times the up / down triggers ? :thinking:

8

Yes I did and it doesn't work for me. Admittedly I didn't key-bind the script but ran it from a terminal so I'm not sure what holding down the key continuously would do. Not much I suspect ... the script has to be re-initialized to get the right value.

What would certainly work IMO:

Is having a more fine tuned brightness-down below i.e 20 or 10%. Like ultimately going down/up to 1 (integer not percent) in 2 or 3 or 4 steps, certainly not more.
BTW: Using the "g" flag would also take away the necessity of using 'awk' to read line specifics but would make it hard to read percentages. :thinking:

Meaning: Keep the standard 10% increments until it reaches 10% (arbitrary choice) and start halving the integer value 'brightnessctl g' and the use of 'bc'.

Which is why "halving" the found value works better than setting a fixed incremental change. :innocent: .

9

Hence me making this with E16 in mind, I'm running my navigation stuff on an old Yoga 2.13 with touch-screen. E wont run nicely on that, especially if it goes into suspend. ..... for the new E: I'll leave that to Raster&co. and to you :smiley:
OTOH: To keep Retrowave alive and kicking we will have to keep E16 going nicely, don't we? :smiley14:

TIP: If/when using 'yad' there's a "--timeout" option like i.e:
yad button=OK:0 --text="Brightness: <b>`brightnessctl g`</b>" --center --timeout=1 --image=preferences-system-brightness-lock

10

Like ultimately going down/up to 1 (integer not percent) in 2 or 3 or 4 steps, certainly not more.

This is exactly what is meant to do, a smart step mode

note that it needs the argument parameter "down" or "up"

yes you can try to bind it to have a much smoother experience to see how increase/decrease the brightness, but the question is more like "why it doesn't work" ?

in my case:

  • just tried on my thinkpad laptop, i changed the XF86MonBrightnessDown to "zenity --info" just to verify that the hotkey is triggered from E16 and not another maybe more internal way
  • it worked on my laptop correctly, in fact the "steps" are quite visible in their "different degrees" if you press the hotkey multiple times faster, it worked just as expected, it was like maybe 25 presses in total to cross the full range

I'm thinking is not detecting correctly your card (which brightnessctl should have the same issue), I just commited a debug message so you can get some info, try it this way:

EL_DEBUG=3 brightnessctl-elive down

For example in my desktop computer, which I don't think I can control the brightness of the external screen, I have this error:

~ ❯❯❯ EL_DEBUG=3 brightnessctl-elive down
brightnessctl: invalid option -- '1'
... (help)

yeah well, I started already to work on the new E, but a lot of work is remaining and many future betatestings will be required :slight_smile: stay tunned!

Yeah of course, what i meant is that i cannot invest limited resources in E16 if there's many work on E26, but of course this is relative, meaning "make it working & compatible, not perfect & polished"

In short: E16 will use brightnessctl-elive which is a smarter wrapper (so let's try to make it working in a better way, like for cases of low light like yours), E26 will use its own module

11

UPDATE: the last version includes a better report of "available devices" if the brightness failed, try it directly from the updated script link (or "apui elive-tools" and run it from the system)

12

I think you got me wrong there:
Your script with the up/down arguments work just fine as you intended it should and I don't doubt it will work on the E16 keybindings. I was merely suspecting it wouldn't continuously darken or lighten by holding down the key i.e a key-release would be necessary to re-initiate the script and update the variables.

But as intentions go, you're missing the greater point:
25 clicks to go from minimum to maximum (or vice versa) is way, way too many and certainly uncomfortable. :shocked:

IMHO nobody needs "fine-tuning" in the top or middle sector of the brightness scale but some do down at the lower end. I (and @Franc ) most certainly do. .... possibly even more people.

Percentages are crude but good enough, lowering by an incremental decrease of "1" below 1% is a form of masochism on my Thinkpads.
That's where 'halving' (dividing by 2) is just a perfect option because then it ultimately doesn't matter what integer value 1% has. The lower you get the finer the changes are, in every case.

To be clear:
On my current X1, 1% = 337. That would be 336 steps to get down to 1 .... :shocked:
Using 'bc' and halving below 1%, it would be 7 or 8 steps.

sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 165 (1%)
	Max brightness: 24242

~ ❯❯❯ sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 82 (0%)
	Max brightness: 24242

~ ❯❯❯ sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 41 (0%)
	Max brightness: 24242

~ ❯❯❯ sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 20 (0%)
	Max brightness: 24242

~ ❯❯❯ sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 10 (0%)
	Max brightness: 24242

~ ❯❯❯ sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 5 (0%)
	Max brightness: 24242

~ ❯❯❯ sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 2 (0%)
	Max brightness: 24242

~ ❯❯❯ sudo -n brightnessctl s `echo $(brightnessctl g)/2 |bc`
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 1 (0%)
	Max brightness: 24242
1 Like
13

You are correct there AFAIK. The machine cannot communicate with the external screen like a laptop can, to it's built-in screen. Even a connected screen (to the laptop) through HDMI, display-port or USB-c will not respond.

Maybe there are some (expensive) high end screens out there that have an internal OS that can be communicated with but I haven't come across any, yet.

Might be a good question for Rasterman .... after all my Samsung TV does run his GUI, the icons are a dead give-away. :smiley:

14

yeah that's not possible on E16 because many factors (its basically a call to execute an external tool), not sure about E26...

We need to betatest it a bit... note that in line 37 the default increment is 6% (before was 5%) which is good, in line 39 sets the % to 4 (which stills similar to 5%) if the brightness stills bigger than 20%, then 2% if bigger than 10%, and finally 1% if is between 2 and 10 %. I think this combo is pretty good, but I could change the percent values to be 6, 5, 4, 2. Instead of 6, 4, 2, 1 :thinking:

yeah but stills a better alternative than the previous one, already made (I only need to change the e16 hotkeys to this new tool if works better, which seems so)

I'm not sure to understand, but below 2% the steps are in (1) integers instead of percentage. You mean to use an integer of value 2 instead of 1 because otherwise will be too much keypresses for the 1 steps?

Update: improved logic:

Actually I think the screen brightness (may) works on E26 :thinking: not sure...

15

I meant Raster might know if the external screen's own (Samsung) OS would/could react to communication from the machine OS.
On E26 when connecting an external screen to my laptops (I don't have desktops) it wont dim the external either.

No I mean: Divide the found integer value by 2.
That will mean fairly big jumps at the start of the 1 or 2% (or even 10%) and will quickly become smaller going down to integer 1 or 0.
The higher you start dividing, the relatively larger the steps will be in the beginning.

The accompanying % jumps (starting from 10%) would be 10% ->5% -> 2.5% -> !.25% etc, etc. until it reaches integer 3 or 2. After that it will be 1 and subsequently 0 , as simple 'bc' doesn't do floating point.

The magic is in: echo $(brightnessctl g)/2 |bc
If done cleverly, it will make all those "elif" arguments superfluous. :madness:

16

Heil!

On e.g Dell 4800, even 1% is quite bright at night (I use it on day light)...
So here, a half or so should be a plus...
Perhaps is possible a tuning with a curve or equalizer style?
In any usual cases, mid & full light can be standard & minimum in fine rule, eventually with specific setting as "my preferred lowest is at 0.5, 1, 3%..."?
Or with a standard curve with just low level at best precision..?

Salutations!

17

actually it does it like that but... do you mean to go subsequently to 1-2 integers going up (more brightness) or going down (darker) ? now im confused... i assume you meant darker

Try the last version of the tool, I did many changes, I think it behaves quite good on my laptop

not really, as said before some screens has a range between 0 and 256, others between 0 and 100, others 0-10, etc, so using integers are not a good option, is much better to use percentages, on which if you say "do 20 a total of steps" (using in this case the value 5%), it will be like this for all screens / computers. The integer mode is only switched when the brightness is below 1-2 %

@Franc try the last version of the tool to see if works better than the previous brightness tool, how to do it:

  • run apug
  • edit the .e16/bindings.cfg file and change these contents:
# KeyDown    -        XF86MonBrightnessDown exec sudo -n brightnessctl s 5%-
# KeyDown    -        XF86MonBrightnessUp   exec sudo -n brightnessctl s 5%+
KeyDown    -        XF86MonBrightnessDown exec brightnessctl-elive down
KeyDown    -        XF86MonBrightnessUp   exec brightnessctl-elive up
  • run "ctrl + alt + end" to reload your desktop
  • use the hotkeys to change brightness and see if the "curve" as you said is better now
18

Yes, really!!
All of them use integers ..... so there's no going below integer 1 other than 0....but 1% or 10% or 5% are totally dependent of the available range.
Dividing the previous integer by 2 will always work, giving 50% of the found previous value (so NOT a + or - % of the max value).
For 'bc' one can mimic fractions if needed by i.e first multiplying by 3 and then dividing by 2 ... it's simple math. :innocent:

That's arbitrary i.e it could be at 10% or whatever, depending on the wanted speed of decreasing or increasing .... but yes, there has to be a point where integers take over.
Personally I'd take it at 30 or 20% because I don't see any real benefit of fine-tuning mid or top range brightness, only of the low range.
Me I want to tone down fast when the sun sets (especially in this time of year) allowing me to check the screen without rendering me "blind" for a moment to the outside world. After a while it's a very tiring process for the eyes.

Admittedly, the first 2 posts weren't very clear on that integers were being used, confusingly @Franc stating the lowest screen value as 1% where integer '1' was meant.

19

Which is where the integers come in.
At the lowest, 1% can indeed still be too light.
In my case:

 ❯❯❯ sudo brightnessctl set 1%                                                                                                                                                                  
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 242 (1%)
	Max brightness: 24242

where using the integer value gives:

~ ❯❯❯ sudo brightnessctl set 2
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
	Current brightness: 2 (0%)
	Max brightness: 24242

Meaning there's quite a range of usable settings below 1% ..... unless your max range doesn't exceed '10', which is unlikely.

1 Like
20

I did an 'apug' and ran "brightnessctl-elive down" in a terminal which resulted in the brightness going down (ever so slowly) until it reached 3%. After that it went to 0 and turned off the backlight. Is that a bug or a feature? :frowning:

  • Anyway, I think we should avoid turning off t he backlight with brightnessctl i.e stop at integer '1'. On E26 the keys become unresponsive and requires jumping through a few hoops to get it back on.

Given some time tomorrow (it's late Sunday night here) I'll start mucking around in the "brightness-elive" script and alter it to what I think suits me the best....including a pop-up.

Practically speaking I think we actually are in agreement only ..... IMO you are focusing on practical scripting issues to solve a conceived issue and as a result, way too linear in your solutions.

The issue is NOT ONLY the total number of incremental steps but also the way to manipulate the backlight at very low settings. Personally I think 6-10 steps should suffice to get down to 1.

1 Like
21

I really think I don't underand your point :slight_smile: sorry.

What I meant is that using integers is very difficult because some machines will require steps of 5 and some others steps of 50, instead, using percentage values the integeres are automatically calculated inside the tool and then passed as integeres when set.

So for example if you decrease with 5%, in some machines the tool will use 5 integers to be set and in some 50, in other words, the integeres are automatically proportional

The only thing that does the -elive tool is that it uses the % values as in the other way, except for when the value are very low (low light) which then it starts using integer values to have smaller steps, in a "curvature" way, in order to fine-tine the darker light which in low-light environments as you mentioned is handy to have it fine-tuned

Mmmh... Ok I think I understand now, what you mean is something like that (in equivalent percentages)?

100 -> 50 -> 25 -> 12 -> 6 -> 3 -> 1

It makes sense... Mmmh, and this is exactly 7-8 steps in total :thinking:

Is not 100 -> 50 too much? its entirely half, I assume some people would want to have it bright but not at max, for example 90% or 80%

Yeah exactly, the actual configuration is to use 2 integers when 2% and 1 integers when 1%, maybe 20% is too high imho :thinking:

A good setup I think can be to have it in steps of 10% between 20%-100%, and below 20% use your "divider" technique, until 1% which will be steps of 1 integer

lol

After that it went to 0 and turned off the backlight. Is that a bug or a feature?

Its a feature I assume, setting the brightness to 0 makes no light in the screen, I think its more useful and annoying (unless the user don't know the hotkey to incrase light, which is unlikely)

In E26 can be a problem to turn off the light, so the user -could- do it from the mouse slider and then unable to know where to click... that's not the case in E16 on which there's no gui but only the hotkey

Yes and no, is true that "more steps are annoying" but we need to have a little high range too, because is better to "be able to" adjust it to the need of the user (too bright! too dark! damn! where's the middle point??) but of course without making it a hand pain :slight_smile: