On Thu 27 Jun 2019 at 18:44:59 (+0300), Reco wrote:
> On Thu, Jun 27, 2019 at 10:24:51AM -0500, David Wright wrote:
> > That has led to finding these lines in systemd's journal:
> ...
> > Jun 27 09:47:06 west systemd-backlight[615]: [0;1;31mFailed to write
> > system 'brightness' attribute: Input/output error[0m
> ...
> > which suggests there's something wrong with the backlight.
>
> Hardly. More likely there's something wrong with the appropriate kernel
> facility.
I'm afraid that's unlikely, based on the evidence that you snipped:
> On Fri 10 May 2019 at 13:20:39 -0500, David Wright wrote:
> > My interest in this stems from a Laptop on which you are blind until
> > the kernel loads (ie text pours down the screen). No boot selection
> > menu, no CMOS screens, no Grub screens.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
When the laptop is being powered up regularly, the display works for
about as long as the progress bar on the DELL screen takes to cross
from side to side: I would estimate it's about one second. The problem
came on gradually in Jan 2017. During use, the screen would flicker
a little, then die.
So my strategy was (1) set the CMOS to boot USB/optical/hard drive in
that order. I did that a year ago, after it had been powered off for
a week. (2) Leave a stretch installation USB stick by it, ready for
whenever I got a chance to use it. (3) Go on holiday. When I got
back, I had a long enough period with a display showing to get to:
┌────────────────┤ [!!] Continue installation remotely using SSH
├────────────────┐
│
│
│ Start SSH
│
│ To continue the installation, please use an SSH client to connect to the IP
│
│ address 192.168.1.xxx fe80::xxx:xxxx:xxxx:xxxx and log in as the
"installer" │
│ user. For example:
│
│
│
│ ssh instal...@192.168.1.xxx
│
│
│
│ The fingerprint of this SSH server's host key is:
│
│
│
│ SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
│
│
│
│ Please check this carefully against the fingerprint reported by your SSH
client.│
│
│
│ <Continue>
│
│
│
└─────────────────────────────────────────────────────────────────────────────────┘
at which point I'm home and dry.
> Basically what this systemd unit tries to do is to write a saved value
> to /sys/class/backlight/intel_backlight/brightness.
> Kernel responds to this with EIO, which is unusual for the laptop (to be
> expected for the desktop as there's no backlight there).
>
> It may be possible to workaround this with certain knobs of i915 kernel
> module (enable_dpcd_backlight or invert_brightness), I'd try the latter
> first.
> I.e. try adding "i915.invert_brightness=1" or
> "i915.enable_dpcd_backlight=1" to the kernel's commandline.
Yes, I've also looked at the values from /sys/…/*backlight/… and they
all behave sensibly. But the screen flickers a little, then goes out.
That's why I think it might be something like a capacitor charging up.
Over a period of weeks, it could discharge back to behaving normally.
But I'm not looking for a fix to the problem, just workarounds to make
it possible to do things like install, that require the early screens
which the external monitor won't display.
Cheers,
David.
