Subject: initscripts: brightness init script sets brightness to zero, thus blanking laptop display

From: Martin Steigerwald <[email-masked]>
Date: Mon, 11 Oct 2021 18:19:24 +0200

Package: initscripts
Version: 2.96-7+devuan1
Severity: normal
X-Debbugs-Cc: [email-masked]

Just updated Devuan Ceres today and found the display being blanked during
the boot process. I was able to recover over SSH using

% brightnessctl
Device 'intel_backlight' of class 'backlight':
        Current brightness: 0 (0%)
        Max brightness: 512

% brightnessctl set 100%
Updated device 'intel_backlight':
Device 'intel_backlight' of class 'backlight':
        Current brightness: 512 (100%)
        Max brightness: 512

Yet running '/etc/init.d/brightness start' blanked the display again. This
is due to:

% cat /var/lib/initscripts/brightness.intel
0

I have no idea how this value got into this file. The display was certainly
not at 0% brightness as I rebooted after the update.

Expected result:

Never ever blank the display on boot even in case
'/var/lib/initscripts/brightness.intel' contains the value zero.

Just don't.

Expected result 2:

Safe the right value to '/var/lib/initscripts/brightness.intel'. Zero is
definitly not it.

If I run:

% echo 512 > /var/lib/initscripts/brightness.intel
% /etc/init.d/brightness start

After sending this bug report I will reboot and see whether it will remember
this value. Otherwise I will 'chattr +i' this file for now.

This is on a ThinkPax X260 with Intel on board graphics from
Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz CPU.

Thanks,
Martin

-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 4 (daedalus/ceres)
Release:	5
Codename:	daedalus/ceres
Architecture: x86_64

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages initscripts depends on:
ii  lsb-base  11.1.0
ii  sysv-rc   2.96-7+devuan1

Versions of packages initscripts recommends:
ii  e2fsprogs  1.46.4-1
ii  psmisc     23.4-2

initscripts suggests no packages.

-- no debconf information

---

From: Mark Hindley <[email-masked]>
Date: Mon, 11 Oct 2021 18:06:44 +0100

Martin,

Thanks for this.

The brightness initscript seems to save
/sys/class/backlight/intel_backlight/brightness to
/var/lib/initscripts/brightness when it is stopped.

On your system, what does the /sys/class/backlight/intel_backlight/brightness
contain?

Mark

---

From: Martin Steigerwald <[email-masked]>
Date: Mon, 11 Oct 2021 22:19:22 +0200

Dear Mark.

Mark Hindley - 11.10.21, 19:06:44 CEST:
> On your system, what does the
> /sys/class/backlight/intel_backlight/brightness contain?

I can check tomorrow again. However… after I wrote "512" to the
"/var/lib/initscripts/brightness" file, brightness is set correctly after 
reboot. So I am not sure I can reproduce the original condition after 
the update anymore.

So or so, I think it would be good to ensure a minimum brightness level, 
as a completely blank display can only be fixed with a live Linux, SSH 
access or some other out of band management access.

Best,
-- 
Martin

---

From: Martin Steigerwald <[email-masked]>
Date: Tue, 12 Oct 2021 09:36:24 +0200

Dear Mark.

> /sys/class/backlight/intel_backlight/brightness contain?

I think I know what happened.

After booting the laptop I get:

% cat /sys/class/backlight/intel_backlight/brightness
512

However after KDE Plasma blanked the screen due to inactivity I got:

% cat /sys/class/backlight/intel_backlight/brightness
0

Now when I shutdown the system regularly using the GUI, Plasma would 
raise the brightness again as I move the mouse pointer. However, when I 
reboot from SSH as I did yesterday after the update, it won't.

The script takes writes zero into its state file and that it is.

Due to that I think the whole assumption that it is a sane idea to 
restore the backlight state to what has been set at the time of 
rebooting is fundamentally broken.

Actually it was one of the reasons why I switched from systemd to runit. 
Cause at one point Systemd in Debian was configured to do something 
similar and it causes some of my machines to boot up with blank and at a 
later at least very dark display.

Of course you may argue not to reboot a desktop machine via SSH. But why 
wouldn't I do so for my music player laptop?

I do not have a good idea on how to fix this issue at the moment. A work-
around would be to ensure a minimum brightness of at least 10% or 20%. 
Another idea would be to tell the desktop environment to unblank the 
screen before logging off or ask the desktop environment developers to do 
so in all cases. Or you'd just use say 80% of brightness as a default 
value and put a file into /etc to let the user manually configure it.

The best solution would be to somehow grab the *intended* brightness 
value during operation and not ever take the one during inactivity where 
the screen is blanked. But also this depends on the desktop environment. 
So… it is likely to become messy and complex.

My personal work-around for now will likely be to disable the stop 
operation of that script.

Best,
-- 
Martin

---

From: Mark Hindley <[email-masked]>
Date: Tue, 12 Oct 2021 11:07:53 +0100

Martin,

Thanks for your analysis. At least that makes sense, even if a clean solution is
not immediately obvious.

Creating and artificial minimum seems rather arbitrary and would a minimum of,
say, 20% of the maximum value even be sane and suitable on all hardware? I don't
have any suitable hardware for real testing, so would have to rely on reports
from you and others.

Getting all DEs to cooperate in unblanking seems a tall order.

I agree the script seems suboptimal in many ways.

Maybe we could support configuring a minimum in /etc/default/brightness?

At least you have a workaround that will avoid the issue for you again. If you
get any other ideas about clean fixes, do say.

Mark

---

From: Olaf Meeuwissen <[email-masked]>
Date: Tue, 12 Oct 2021 20:14:17 +0900

Hi,

> access or some other out of band management access.

Does this mean that even switching to the console (Ctrl-Alt-F1, etc)
doesn't give you a screen where can see what you're doing?

Just wondering,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join

---

From: Martin Steigerwald <[email-masked]>
Date: Tue, 12 Oct 2021 16:52:32 +0200

Olaf Meeuwissen - 12.10.21, 13:14:17 CEST:
> > "/var/lib/initscripts/brightness" file, brightness is set correctly
> > after reboot. So I am not sure I can reproduce the original
> > condition after the update anymore.
> > 
> > So or so, I think it would be good to ensure a minimum brightness
> > level, as a completely blank display can only be fixed with a live
> > Linux, SSH access or some other out of band management access.
> 

Yes. I tried via Ctrl-Alt-F1 on the laptop and via SSH with "chvt 1". 
Nothing.

Ciao,
-- 
Martin

---

From: Jacob Lundberg <[email-masked]>
Date: Tue, 12 Oct 2021 10:19:50 -0700

> get any other ideas about clean fixes, do say.

Why not just refuse to *update* to 0 at shutdown.  It seems like 0 is a 
special case the user is fairly unlikely to have set it to themself (but 
if they do want 0 they are probably technical enough to update the 
setting file on their own).

-Jacob

---

From: Martin Steigerwald <[email-masked]>
Date: Wed, 22 Dec 2021 11:19:17 +0100

Dear Mark, dear Jacob

Jacob Lundberg - 12.10.21, 19:19:50 CET:
> > At least you have a workaround that will avoid the issue for you
> > again. If you get any other ideas about clean fixes, do say.
> 
> Why not just refuse to *update* to 0 at shutdown.  It seems like 0 is
> a special case the user is fairly unlikely to have set it to themself
> (but if they do want 0 they are probably technical enough to update
> the setting file on their own).

I think that would be a good idea.

I'd really welcome this after I "bricked" another device due to exactly 
this bug. I needed to put GRML to an USB stick and boot from there in 
order to recover.

Have a relaxing, quiet and peaceful time, a merry Christmas!

Best,
-- 
Martin

---

From: Mark Hindley <[email-masked]>
Date: Wed, 22 Dec 2021 11:47:55 +0000

Martin,

> this bug. I needed to put GRML to an USB stick and boot from there in 

How does the attached patch look? Are you able to test?

Thanks.

Mark
From 0bbb9d27a673826a2fa2611c62913107a7809f88 Mon Sep 17 00:00:00 2001
From: Mark Hindley <[email-masked]>
Date: Wed, 22 Dec 2021 11:42:29 +0000
Subject: [PATCH] brightness initscript: don't save value of 0 when stopping
 (Closes: #617).

Fix for Devuan #617.

Some DEs switch off the backlight when idle. If the box is rebooted remotely in
this state, 0 is copied to /var/lib/initscripts/brightness which causes a blank
display on reboot.
---
 debian/src/initscripts/etc/init.d/brightness | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/debian/src/initscripts/etc/init.d/brightness b/debian/src/initscripts/etc/init.d/brightness
index 2b4921f7..c1a5f1fd 100755
--- a/debian/src/initscripts/etc/init.d/brightness
+++ b/debian/src/initscripts/etc/init.d/brightness
@@ -67,6 +67,10 @@ do_stop() {
 	local label=$1 knob=$2 max=$3 file=$SAVEFILE_PREFIX${1:+.$1}
 	test -e "$knob" || return 0
 
+	# If the backlight is off, don't save to avoid blank display after
+	# reboot. See Devuan #617.
+	test "$(cat $knob)" -eq 0 && return 0
+
 	test x"$VERBOSE" = x"no" || \
 	    log_action_begin_msg Saving $label brightness level
 	cat "$knob" >"$file"
-- 
2.20.1

---

From: Martin Steigerwald <[email-masked]>
Date: Wed, 22 Dec 2021 16:42:54 +0100

Hi Mark.

Mark Hindley - 22.12.21, 12:47:55 CET:
> > I'd really welcome this after I "bricked" another device due to
> > exactly this bug. I needed to put GRML to an USB stick and boot
> > from there in order to recover.
> 

The patch looks good to me. I think I am able to test it on one machine. 
May take some time though.

Best,
-- 
Martin

---

From: Martin Steigerwald <[email-masked]>
Date: Thu, 23 Dec 2021 14:47:19 +0100

Mark,

> How does the attached patch look? Are you able to test?

I tested on a ThinkPad laptop with Intel graphics:

Without patch:

root@somehost:/var/lib/initscripts# cat brightness.intel 
512
root@somehost:/var/lib/initscripts# /etc/init.d/brightness stop
root@somehost:/var/lib/initscripts# cat brightness.intel 
0

With patch:

root@somehost:/var/lib/initscripts# echo 512 > brightness.intel 
root@somehost:/var/lib/initscripts# cat brightness.intel 
512

root@somehost:/var/lib/initscripts# /etc/init.d/brightness stop
root@somehost:/var/lib/initscripts# cat brightness.intel 
512

I think it should work.

Thanks,
-- 
Martin

---

From: Mark Hindley <[email-masked]>
Date: Sun, 26 Dec 2021 09:56:07 +0000

Martin,

> I think it should work.

Thanks.  I will build a new version over the next few days.

Mark

---

From: Mark Hindley <[email-masked]>
Date: Thu, 13 Apr 2023 14:06:11 +0100

Control: tags -1 pending patch

Martin,

> Thanks.  I will build a new version over the next few days.

My apologies, this completely slipped my mind.

I have merged it for the next upload.

Mark