Brightness module?

Altoid · 2025-03-10 09:05:32

Hello:

I run Pi-hole in a headless Devuan Chimaera VM in my box:

root@chimaera:~# uname -a
Linux chimaera 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
root@chimaera:~#

The last Pi-hole upgrade (to 6.0.4) had a small issue and I had to remove the apparmor service (which was not running) for the upgrade to complete properly. Jury is still out there as to what was going on so it is a matter to be dealt with in another thread.

The thing is that while going over the service status list I found one which I did not know about and had never seen before:

root@chimaera:~# service --status-all
--- snip ---
 [ - ]  brightness
--- snip ---
root@chimaera:~#

I have no idea how it got there.

I see it is all over:

root@chimaera:~# locate brightness
/etc/init.d/brightness
/etc/rc0.d/K01brightness
/etc/rc6.d/K01brightness
/etc/rcS.d/S12brightness
/etc/systemd/system/brightness.service
/usr/src/linux-headers-5.10.0-9-amd64/include/config/leds/brightness
/usr/src/linux-headers-5.10.0-9-amd64/include/config/leds/brightness/hw
/usr/src/linux-headers-5.10.0-9-amd64/include/config/leds/brightness/hw/changed.h
root@chimaera:~#

But this is a headless VM installation and I never installed a desktop.
And it is certainly not a laptop.

The problem is that I cannot get rid of it.
Or do anything with it:

root@chimaera:~# service brightness status
root@chimaera:~# 
root@chimaera:~# service brightness start
root@chimaera:~# 
root@chimaera:~# service brightness stop
root@chimaera:~#

Where did this come from?
How can I get rid of it?

Best,

A.

fsmithred · 2025-03-10 10:52:32

$ apt-file find init.d/brightness
initscripts: /etc/init.d/brightness

I don't think you can get rid of it. You're not the only one who never noticed this.

# Short-Description: Save and restore brightness level between restarts.
# Description:       This script saves the brightness level between restarts.
#                    It is called from the boot, halt and reboot scripts.

Altoid · 2025-03-10 12:06:47

Hello:

fsmithred wrote:

$ apt-file find init.d/brightness

Yes, I had already found it there.

My Daedalus installation also has it:

~$ locate brightness
/etc/init.d/brightness.dpkg-dist
/etc/systemd/system/brightness.service
--- snip --- 
~$

But it is not a in the service status printout:

~$ sudo service --status-all | grep brightness
 [ ? ]  alsa-utils
 [ ? ]  binfmt-support
 [ ? ]  hwclock.sh
 [ ? ]  kmod
 [ ? ]  lpd
 [ ? ]  mount-configfs
 [ ? ]  networking
 [ ? ]  vboxautostart-service
~$

Q1: why do all these other services show up when I am not asking grep to find them?

Then this is the script I find in /etc/init.d:

~$ ls /etc/init.d/ | grep brightness
brightness.dpkg-dist
~$

Q2: why it is being started in my Chimaera headless VM but not in my Daedalus desktop installation?

The Chimaera VM does not have the same name for the /etc/init.d/brightness.dpkg-dist script.

root@chimaera:~# ls /etc/init.d | grep brightness
brightness
root@chimaera:~#

The script in the Chimaera VM indicates the usage:

root@chimaera:~# cat /etc/init.d/brightness
#!/bin/sh
### BEGIN INIT INFO
# Provides:          brightness
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     S
# Default-Stop:      0 6
# Short-Description: Save and restore brightness level between restarts.
# Description:       This script saves the brightness level between restarts.
#                    It is called from the boot, halt and reboot scripts.
### END INIT INFO

readonly SAVEFILE_PREFIX=/var/lib/initscripts/brightness

. /lib/init/vars.sh
. /lib/lsb/init-functions

do_invoke() {
	local rv=0 rc
	# ACPI (without explicit label)
	do_$1 '' \
	    /sys/class/backlight/acpi_video0/brightness \
	    /sys/class/backlight/acpi_video0/max_brightness
	rc=$?
	test $rc -lt $rv || rv=$rc
	# Intel
	do_$1 intel \
	    /sys/class/backlight/intel_backlight/brightness \
	    /sys/class/backlight/intel_backlight/max_brightness
	rc=$?
	test $rc -lt $rv || rv=$rc
	# could insert others using the same scheme here
	return $rv
}

do_status() {
	local label=$1 knob=$2 max=$3 file=$SAVEFILE_PREFIX${1:+.$1}
	test -e "$knob" || return 0

	MSG="Current${label:+ $label} brightness level is $(cat "$knob")"
	if test -f "$file"; then
		log_success_msg "${MSG}, saved value is $(cat "$file")"
		return 0
	fi
	log_failure_msg "${MSG}, there is no saved value"
	return 4
}

do_start() {
	local label=$1 knob=$2 max=$3 file=$SAVEFILE_PREFIX${1:+.$1}
	test -e "$knob" || return 0

	test x"$VERBOSE" = x"no" || \
	    log_action_begin_msg Initialising $label brightness level

	if test -f "$file"; then
		cat "$file" >"$knob"
	else
		cat "$max" >"$knob"
	fi
	local rv=$?
	test x"$VERBOSE" = x"no" || log_action_end_msg $rv
	return $rv
}

do_stop() {
	local label=$1 knob=$2 max=$3 file=$SAVEFILE_PREFIX${1:+.$1}
	test -e "$knob" || return 0

	test x"$VERBOSE" = x"no" || \
	    log_action_begin_msg Saving $label brightness level
	cat "$knob" >"$file"
	local rv=$?
	test x"$VERBOSE" = x"no" || log_action_end_msg $rv
	return $rv
}

case $1 in
(start|restart|reload|force-reload)
	do_invoke start
	;;
(stop)
	do_invoke stop
	;;
(status)
	do_invoke status
	;;
(*)
	echo >&2 "Usage: $0 {start|stop|restart|reload|force-reload|status}"   ##########   <----
	exit 3
	;;
esac
root@chimaera:~#

What is going on?

Best,

A.

fsmithred · 2025-03-10 16:00:52

*.dpkg-dist is the saved copy of a new config file when the old one was kept in place. I think if you have brightness.dpkg-dist but not brightness, then something is wrong. Converseley, *.dpkg-old is the old version that's saved when it gets replace with the new one. I think you only get that when you tell debconf to use the package maintainer's (new) version rather than the old version that you modified from the default.

Sorry, I have no other answers.

Altoid · 2025-03-10 18:23:08

Hello:

fsmithred wrote:

brightness.dpkg-dist is the saved copy of a new config file when the old one was kept in place

Starts to make sense.

/etc/init.d/brightness.dpkg-dist belongs to what is today a Daedalus installation.

But (IIRC) started as Jessie (!) and was dist-upgraded to ASCII and eventually Beowulf.
Then to a backported kernel and when Beowulf was about to be archived, almost directly to Daedalus via Chimaera.
This because the XFCE upgrade in Chimaera generated a totally unusable desktop environment.

I have to say that compared to anything MS branded I have had to deal with, it was smooth as silk. 8^ )

... if you have brightness.dpkg-dist but not brightness, then something is wrong.

I don't recall ever seeing brightness in the list of services printed out by service --status-all, much less messing with debconf which I don't have a clue about.

I checked my Asus 1000HE netbook (runs on a 32bit Chimaera) and service brightness status properly reports current and saved brightness and intel brightness levels and just like in my Chimaera VM, it cannot be stopped or started. But then it is only one LCD monitor, my Daedalus box runs three monitors with two NVidia cards with brightness levels controlled individually via the monitors' screen controls

My guess is that it does not report anything with service brightness status because it is a headless VM.
ie: no monitor.

So the problem (if one at all) would be the lack of a brightness service in my Daedalus installation, situation I cannot account for.
That said, besides the curiosity it generates, I have not experienced any issues.

fsmithred wrote:

Sorry, I have no other answers.

No problem, I look around and see if I catch something worth reporting.
If not, I'll may well leave it at that.

Edit:
I just realised that Daedalus is the first version of Devuan in which I installed the nouveau drivers for my NVidia cards.
Had no choice as there was no clear way to get the OEM drivers working in Linux.

Maybe that has something to do with the module not being present?

Thanks for your input.

Best,

A.

Last edited by Altoid (2025-03-10 19:18:25)

Altoid · 2025-03-16 16:53:03

Hello:

fsmithred wrote:

... don't think you can get rid of it.

I looked all over and found nothing, just links to fiddling around with power management settings. 8^/

But not on how to remove the %&$# brightness service.
Which probably exists because of crappy and unreliable PM applications.

All I can say with absolute a high degree of certainty is that I had nothing to do with the brightness service not running in my Devuan Daedalus box.

Had I been aware of it, I would have tried to get rid of the damn thing ipso facto.

Like I said, monitor controls have always worked well enough for me.
As far as I am concerned, this brightness service is just another solution looking for a problem.
No wonder it is enabled by default and it will not respond to any of the the usual service commands.
ie: start|stop|restart|reload|force-reload|status which (BTW) are specified in the script.

In any case, some update/upgrade in the long list that have worked on my file system from Jesse to Daedalus had the common sense of doing away* with /etc/init.d/brightness and leaving /etc/init.d/brightness.dpkg-dist in its place and in doing so, kept the brightness service from being loaded.

I concluded that it was probably just a name change, so I did the same thing on my headless Devuan Chimaera VM.
And achieved the same result. 8^)

Now, the service --status-all request does not include brightness.

~# service --status-all
 [ - ]  bootlogd
 [ - ]  bootlogs
 [ - ]  bootmisc.sh
 [ - ]  checkfs.sh
--- snip ---
~#

I have looked over the logs and found no error.
Is there any special place I should look?

I think we can chalk one up for basic common sense.
Because ...
Wthf does the brightness service have to do running in a headless VM?

Better yet ...
Wthf does the brightness service have to do running in any Linux by default?

Please let me know if I have overlooked something.

Best,

A.

Last edited by Altoid (2025-03-16 21:42:25)

ralph.ronnquist · 2025-03-17 01:56:24

I believe it would merely be a boot action aimed at restoring the brightness at boot up to a level that got captured at power down. So, a comfort utility. But I'm sure one can expand the concept to any level of complication and introduce all sorts of knick-knack with elaborate justifications and then you can add steak knives to that...

Altoid · 2025-03-17 07:46:44

Hello:

ralph.ronnquist wrote:

... a boot action aimed at restoring the brightness ...

Quite so.
That's exactly what it is.

[rant]
And why would that need to be so?
I have never needed any of that.

My three monitors have always had the same brightness values at boot.
One of the SyncMasters 940n has over 70K hours uptime so had to recap it last week but the tubes are a bit dim so a cold environment will make it bit dimmer at boot time, but it only takes a minute or so to get right.

ralph.ronnquist wrote:

... a comfort utility.

Sure, I guess you could call it that.
But when it is needlessly foisted on the user and root cannot removed it by the usual means, it immediately turns into a nuisance.

As you know, the list of crap like that in today's Linux distributions is endless.
[/rant]

Thanks for your comment.

Best,

A.

zapper · 2025-03-18 05:16:31

light and set color temperature also known as sct or xsct are good ways to do brightness.

And if you use a window manager, in some you can have it start its command once you login.

light -S 75

xsct 2000 1.0

those are ones I tend to use for battery life and to ease the pain on my eyes.

delgado · 2025-03-18 13:01:00

Nice tools, zapper!
Thanks for mentioning

The officially official Devuan Forum!

#1 2025-03-10 09:05:32

Brightness module?

#2 2025-03-10 10:52:32

Re: Brightness module?

#3 2025-03-10 12:06:47

Re: Brightness module?

#4 2025-03-10 16:00:52

Re: Brightness module?

#5 2025-03-10 18:23:08

Re: Brightness module?

#6 2025-03-16 16:53:03

Re: Brightness module?

#7 2025-03-17 01:56:24

Re: Brightness module?

#8 2025-03-17 07:46:44

Re: Brightness module?

#9 2025-03-18 05:16:31

Re: Brightness module?

#10 2025-03-18 13:01:00

Re: Brightness module?

Board footer