When I lower the brightness level on my laptop to the lowest setting, my screen turns black and wont turn back on. I have to hard reset my computer.
Any advice?
This looks like a problem with your drivers on Qubes desktop environment, which is xfce by default. I guess searching for a solution on xfce forums might help. I.e. it’s likely not directly related to Qubes.
In Qubes OS I can lower my screen brightness to zero and then increase back to normal. Most other OSes merely limit the minimum screen brightness to a small value that is not zero.
You have multiple things to try out:
- try turning your brightness back
- use the latest kernel in dom0 when booting
- play music in a VM (make sure you can consistently hear the music), and then lower the brightness and check out whether the music halts
- when you believe that your computer dies as your screen goes black, try blindly operating your computer and control it to shutdown normally
- look at logs, in dom0
journalctl
1 Like
@logoerthiner thank you for your reply. I have gone through each step you suggested.
- screen stays off
- Confirmed. I am up to date
- Yes, music keeps playing when the screen goes black
- I am not able to do this
- Here is everything in my log immediately after reboot from a hard reset:
Logs begin at Fri 2022-08-19 06:37:16 EDT, end at Fri 2022-08-19 18:46:37 ED>
Aug 19 06:37:16 dom0 kernel: Linux version 5.15.52-1.fc32.qubes.x86_64 (mockbui>
Aug 19 06:37:16 dom0 kernel: Command line: placeholder root=/dev/mapper/qubes_d>
Aug 19 06:37:16 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floa>
Aug 19 06:37:16 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE regi>
Aug 19 06:37:16 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX regi>
Aug 19 06:37:16 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 >
Aug 19 06:37:16 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 >
Aug 19 06:37:16 dom0 kernel: x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 >
Aug 19 06:37:16 dom0 kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: >
Aug 19 06:37:16 dom0 kernel: x86/fpu: xstate_offset[5]: 1088, xstate_sizes[5]: >
Aug 19 06:37:16 dom0 kernel: x86/fpu: xstate_offset[6]: 1152, xstate_sizes[6]: >
Aug 19 06:37:16 dom0 kernel: x86/fpu: xstate_offset[7]: 1664, xstate_sizes[7]: >
Aug 19 06:37:16 dom0 kernel: x86/fpu: Enabled xstate features 0xe7, context siz>
Aug 19 06:37:16 dom0 kernel: signal: max sigframe size: 3632
Aug 19 06:37:16 dom0 kernel: Released 0 page(s)
Aug 19 06:37:16 dom0 kernel: BIOS-provided physical RAM map:
Aug 19 06:37:16 dom0 kernel: Xen: [mem 0x0000000000000000-0x000000000009efff] u>
Aug 19 06:37:16 dom0 kernel: Xen: [mem 0x000000000009f000-0x00000000000fffff] r>
Aug 19 06:37:16 dom0 kernel: Xen: [mem 0x0000000000100000-0x000000005f033fff] u>
Aug 19 06:37:16 dom0 kernel: Xen: [mem 0x000000005f034000-0x0000000063110fff] r>
Aug 19 06:37:16 dom0 kernel: Xen: [mem 0x0000000063111000-0x0000000063971fff] A>
Aug 19 06:37:16 dom0 kernel: Xen: [mem 0x0000000063972000-0x0000000063bfefff] A>
I’ll take a llok. thanks
@lqz8793 It would be very useful to get the output of lspci in your dom0 terminal, just to see what hardware we’re dealing with.
I have had similar issues with old Apple hardware on Qubes OS, and it was to do with the garbage GPUs nVIDIA custom-made for Apple hardware…
The most recent one now is that the current i915 kernel module has a weird regression where it won’t resume a MIPI-DSI display from S3 suspend, which has stunted the usability of some laptops with Intel GPUs.
Good attempt.
For point 1. Try the kernel-latest (which should be kernel 5.18.16 right now). If your hardware is ultra-new (in 2 years), a new kernel version may introduce different results.
For point 3. Maybe you can try opening a dom0 terminal, type “poweroff” in advance, and lower your brightness. And then press “Enter” to see whether your computer poweroffs. As you have satd that the music continues, it is possible that your computer can respond to your command.
For point 4. Information immediately BEFORE reboot from a hard reset (and after you have set the brightness to zero) are most useful here.
Also try point 5: plug an external monitor via HDMI/VGA/etc and try the same thing.
Also, this is the beginning of every Qubes OS boot process, and doesn’t tell us anything useful, unfortunately. In order to figure out what happened with your display, we need the lines before you rebooted 
If you can’t fit the whole log as plain text, dump it as a file and upload the file, which you can do with these commands in a dom0 terminal:
sudo journalctl > journal.clip
qvm-copy-to-vm $vm_you_use_for_this_forum journal.clip
Obviously replace the $value with the actual VM name.
(But you probably knew this, seeing as you were able to bring up the logs in the first place 
You probably also know that this log could contain some potentially sensitive information about your machine, like your username, hardware serial number, how much RAM you have, etc.; so you probably also know to read it, audit it, redact it before you upload it 
)
@logoerthiner is right. It sounds like either a glitchy udev rule or an outdated kernel/firmware is causing you grief.
@lqz8793, does this screen behave like this on any other Linux-based OS (Ubuntu, Gentoo, Arch, Debian, Fedora, etc)?
@alzer89 Here are the results from lspci:
0000:00:00.0 Host bridge: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers (rev 05)
0000:00:01.0 PCI bridge: Intel Corporation 11th Gen Core Processor PCIe Controller #1 (rev 05)
0000:00:02.0 VGA compatible controller: Intel Corporation TigerLake-H GT1 [UHD Graphics] (rev 01)
0000:00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 05)
0000:00:07.0 PCI bridge: Intel Corporation Tiger Lake-H Thunderbolt 4 PCI Express Root Port #2 (rev 05)
0000:00:07.3 PCI bridge: Intel Corporation Tiger Lake-H Thunderbolt 4 PCI Express Root Port #3 (rev 05)
0000:00:0a.0 Signal processing controller: Intel Corporation Tigerlake Telemetry Aggregator Driver (rev 01)
0000:00:0d.0 USB controller: Intel Corporation Tiger Lake-H Thunderbolt 4 USB Controller (rev 05)
0000:00:0d.3 USB controller: Intel Corporation Tiger Lake-H Thunderbolt 4 NHI #1 (rev 05)
0000:00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller
0000:00:12.0 Serial controller: Intel Corporation Device 43fc (rev 11)
0000:00:14.0 USB controller: Intel Corporation Tiger Lake-H USB 3.2 Gen 2x1 xHCI Host Controller (rev 11)
0000:00:14.2 RAM memory: Intel Corporation Tiger Lake-H Shared SRAM (rev 11)
0000:00:14.3 Network controller: Intel Corporation Tiger Lake PCH CNVi WiFi (rev 11)
0000:00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-H Serial IO I2C Controller #0 (rev 11)
0000:00:15.1 Serial bus controller [0c80]: Intel Corporation Device 43e9 (rev 11)
0000:00:16.0 Communication controller: Intel Corporation Tiger Lake-H Management Engine Interface (rev 11)
0000:00:1c.0 PCI bridge: Intel Corporation Device 43be (rev 11)
0000:00:1f.0 ISA bridge: Intel Corporation Device 4389 (rev 11)
0000:00:1f.3 Audio device: Intel Corporation Tiger Lake-H HD Audio Controller (rev 11)
0000:00:1f.4 SMBus: Intel Corporation Tiger Lake-H SMBus Controller (rev 11)
0000:00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger Lake-H SPI Controller (rev 11)
0000:01:00.0 3D controller: NVIDIA Corporation GA107M [GeForce RTX 3050 Mobile] (rev a1)
0000:74:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5260 PCI Express Card Reader (rev 01)
10000:e0:01.0 System peripheral: Intel Corporation Device 09ab
10000:e0:01.2 PCI bridge: Intel Corporation Device 9a07 (rev 05)
10000:e1:00.0 Non-Volatile memory controller: SK hynix Device 174a
also @alzer89 I cant run any commands or produce any logs after the issue and before reboot because I can’t see anything with the monitor off haha.
thank you for helping!
1, Linux 5.15.57-1.fc32.qubes.x86_64 x86_64
so it seems like Im not up to date?
I try this command but nothing seems to happen. Should I be using a differnet commang to update the kernel?
sudo qubes-dom0-update
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time…
Qubes OS Repository for Dom0 2.9 MB/s | 3.0 kB 00:00
Technically, you can still run commands, you just can’t see what you’re doing. You said before that music plays after you turn your brightness down. This is incredibly important information, which suggests that your computer has not frozen or crashed, which is really good news.
This tells us that:
- Your computer is still feeding a live display to your screen
- Your keyboard and mouse remain responsive (I would imagine the caps lock light still works)
- Nothing appears to have crashed or caused the kernel to panic
- Most importantly, your computer thinks everything is working as normal
- Your computer’s BIOS probably did the first display initialisation on power-on, and then “gave” the kernel a ready-to-go display
(unfortunately, this is more and more common among modern laptops. It keeps the kernel size low, but it allows hardware vendors to withhold key information about how their stuff works
) - It is probably a driver/firmware issue
The logs are always saved as text files in /var/log, and they survive a reboot. Just search (cat | grep) by date and time that you turned your brightness down, and that will help you filter out the millions of lines that don’t really help us fix the problem 
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing kernel-latest kernel-latest-qubes-vm
Give that a try. It may well be that your kernel doesn’t know how to drive your display properly, so this might work…might…
1 Like
In the /sys/class/backlight/whatever-display-you-use you can control the backlight, when the screen goes black you can try to manually set the brightness of the backlight, and see if that turns on the screen.
In the same directory, you can find the current and max values for the backlight, try setting the value to max/2, which should lower the brightness and confirm the value is valid.
echo “1234” > brightness should set the value, but you might need to do it as root.
@alzer89 Thanks so much for your continued help.
Your command worked. I am now at 5.18
I still have the same problem, though. Updating did not fix it.
Waht file do I open in var/log ? I tried to open user.log it told me “failed to open the document … error opening file… access denied”
I usually look at log from journalctl -r and navigate using direction keys on keyboard. Using this command one should be able to see the log corresponding to the last boot, especially between the tick the screen fails and the tick you reboot. This is not related to whether you can control your PC after your screen fails.
Also try followings:
5. plug an external monitor via HDMI/VGA/etc and lower brightness
6. Suspend, either by command or by close the lid of laptop. But first make sure that suspension works in normal cases.
And also as you have mentioned that your /sys/class/backlight is empty, I have a question on it: you meant “The first key you have pressed on lowering screen brightness, your screen fails” or “When you keep pressing the brightness lowering key until the screen goes to zero brightness, your screen fails”, which one - I have thought your case as second one however I feel that you may mean the first one. If the case is first one, could you tell what happens when you turn UP your brightness?
"/sys/class/backlight is empty" is a useful information - this could mean that Qubes OS does not know how to change your screen brightness. Can you click on the “battery” icon of your desktop and see which point your “Display Brightness” is at?
Excellent.
Then it sounds like your brightness controls aren’t doing what they’re supposed to be doing. In that case you should definitely give what @renehoj and @logoerthiner are suggesting. That will likely fix it for you.
You need to be root. Linux won’t just let anyone look at system logs
That will definitely work for whoever is in front of the computer at the time, but I want to be able to get it into this forum so we can see it all
That is one of the causes of your issue. The kernel doesn’t put backlight controls in the places the applications are looking for. They’re there, just not in the places they’re expecting, so they error out.
That is most likely the reason why your display backlight doesn’t go back on.
Don’t worry. That can be fixed quite easily once we know what’s actually going on.
Yes, definitely. @lqz8793 DO THIS.
This will tell us if it’s your computer software or your display hardware that’s messing up.
“But I don’t have an external display…”
Do you have a TV? Plug it into that via HDMI
Literally anything that’s a screen with a cable that fits into one of the ports on your computer will work.
Yes. If your laptop won’t resume from suspend in Qubes OS, maybe don’t try this…yet…at least until we know what’s going on
Hello everyone. I am lqz8793, the OP. Sadly my machine couldnt find my Qubes partition so I had to do a reinstall and I lost my passwords file so I had to make a new account 
It is the second one @logoerthiner
I will try some of these other suggestions and report back. Thank you everyone.