Open emanruse opened 7 months ago
Possibly related: #8281
Perhaps rather #2399
Additional observation:
This system uses 2 screens - one 4K and one 2K. The issue seems to appear while using using the 4K screen only. So far, I have not noticed it while using the 2K one only.
Did you configure VRAM? https://www.qubes-os.org/doc/gui-configuration/
@apparatius
Yes, I have done that long ago (see #7722). However, I am not sure whether it is the issue because:
For example, if you expect to use a 1080p display and a 4k display side-by-side, that is (1920 + 3840) × 2160 × 4 / 1024 = 48600, or slightly more than 48 MiB per qube. After making these adjustments, the qubes need to be restarted.
IMO, the correct calculation (for 8-bit displays) is:
(3840 2160 + 1920 1080) * 4 / 1024 = 40500
Also, I don't quite understand the "per qube" phrase, and "the qubes need to be restarted". What does this mean? There is only one guivm - dom0.
"4" implies 4 bytes, i.e. 4 * 8 bits. The 4K display is 10 bit (1.25 bytes). (something which the documentation does not address), so the actual calculation for my case would probably be:
((3840 2160) 1.25 + ( 1920 1080 )) 4 / 1024 = 48600
IOW, the number now matches the doc for the specific case (a coincidence) but the formula is different.
I am mentioning this not just as a reply to your question but also just in case that may be a signal for something else causing the current issue.
IMO, the correct calculation (for 8-bit displays) is: (3840 2160 + 1920 1080) * 4 / 1024 = 40500
I guess it's not handling it as two separate rectangles but as a single rectangle with a width = display1_width + display2_width
and height = max(display1_height, display2_height)
.
Also, I don't quite understand the "per qube" phrase, and "the qubes need to be restarted". What does this mean? There is only one guivm - dom0.
The gui-videoram-min/gui-videoram-overhead features are passed from dom0 to the qubes using QubesDB and specified VRAM is allocated inside the qube. The Qubes GUI agent is handling this inside qube. And since the gui-videoram-min/gui-videoram-overhead feature are read and applied inside qube during qube start then for new gui-videoram-min/gui-videoram-overhead values to take effect you need to restart the qube.
The gui-videoram-min/gui-videoram-overhead features are passed from dom0 to the qubes using QubesDB and specified VRAM is allocated inside the qube. The Qubes GUI agent is handling this inside qube.
Thanks for explaining.
I guess it's not handling it as two separate rectangles but as a single rectangle with a
width = display1_width + display2_width
andheight = max(display1_height, display2_height)
.
I suppose you may be right (and I will reconfigure assuming you are). But what about bit depth?
I suppose you may be right (and I will reconfigure assuming you are). But what about bit depth?
I'd assume that maximum bit depth would be used if it's handled as a single uniform rectangle.
OK then. I will re-configure this and keep watching it.
It keeps happening with gui-videoram-min set to 97200 (as per the instructions given in the docs) and after rebooting too.
Check dom0 dmesg
for a message like this:
i915 0000:00:02.0: [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
if you have it, follow the advice
After booting, I don't see such message in journal (I do see the PAM error though). I will check again when the issue re-appears but this system uses coreboot and I don't see any "stolen memory size", so probably not possible to follow the advice anyway.
BTW, yesterday it appeared even after quitting LibreOffice (1-2 seconds right after it).
Ever since setting (without typo) the gui-videoram-min using the correct formula and rebooting, I have been experienced another (additional) issue: After the system has been screenlocked for e.g. an hour, I type the password to unlock it and after pressing Enter the screen becomes blank (ON but blank) and nothing seems to be able to restore it. It happens only sometimes.
I switch to a text console, where I am able to login and look at the journal - the additional error mentioned by Marek is not there (and I don't think I have ever seen it at all) but the PAM error is.
During the whole boot session I have not even started LibreOffice.
Just happened a few after a system reboot without even starting LibreOffice or the qube I usually run it in.
Same PAM error in journal (twice), preceded by the FIFO underrun error too (5 seconds before it in the log).
I was playing with the new qui-devices menu when this happened.
Qubes OS release
4.2.1
Brief summary
Working in LibreOffice Calc results in irregular screen blanking.
Steps to reproduce
Watch
journalctl -f
in dom0.Expected behavior
There should be now flaws.
Actual behavior
Very often (can't find exact pattern), the screen would blank for 2-3 seconds and restore itself. The journal always shows errors like:
Sometimes also:
FWIW, there is enough free memory in the VM.