On my Linux systems I like to have shortcuts for tiling and maximizing my windows. In Qubes OS I did the same. In XFCE Window Manager settings I set them like:
Tile window to the top: Super+Home
Tile window to the bottom: Super+End
Tile window to the left: Super+Left
Maximize window: Super+Up
…
However, I notice this buggy behavior in Qubes OS:
If I open a XFCE terminal (or xterm) of a qube (e.g. sys-net, sys-usb, sys-whonix) and resize it many times quickly (e.g. by pressing repeatedly or holding Super+Up) the window disappears after a few seconds and xterm (or XFCE terminal) cannot be run again unless the qube is rebooted. I notice a similar behavior in ‘personal’ qube too. In it though, the inside of the terminal window becomes unresponsive - I can still resize it, it does not crash, but I cannot do anything inside it (type, click on the menu). In dom0 I don’t experience this problem though.
In Qube Manager I checked the logs of the qubes in which I tested and I see out of memory messages. They are similar to those “Xorg invoked oom-killer” ones shown in:
I also attempted a workaround - I increased the memory of sys-net from the default 400MB to 1600MB but that didn’t fix the issue.
FWIW the system I am testing on has 64 GiB RAM and a 4K desktop.
For comparison:
On a very old laptop with 2 GiB of RAM running openSUSE and XFCE on a 2K screen there is no such issue. I can hold e.g. Super+Up forever and it does not cause problems.
Looking again at that guide you give I reread “By default, it is as much as needed for the current display and an additional full HD (FHD) display (1920×1080 8 bit/channel RGBA)”. Testing in 1920x1080 mode though I still experience the issue. I don’t know why, I can only speculate that it might be due to the 10-bit video signal between the computer and the monitor.
I hope you or someone else can answer my previous question, considering the clarification.
I know that “A” in RGBA stands for alpha (transparency) but I have no idea how a video signal can be transparent. Anyway, I assumed that “4” in the formula stands for 4 bytes (8 bits for each of the RGBA channels). So, knowing that 10 is 25% more than 8, I simply added the multiplier 1.25 in the formula for a single 4K 10-bit screen:
(3840 * 2160 * 4 * 1.25) / 1024 = 40500
Then:
qvm-features dom0 gui-videoram-min 40500
and rebooted the computer in order to restart all qubes.
Result: the issue remains.
I even tried not to reboot the whole system, supposing that the change might have not persisted (I have no idea how to check) and repeated the command in dom0. Then I simply restarted sys-net (and the qubes which depend on it).
As this is really annoying (and looks buggy) I even tried doubling gui-videoram-min and set it to 81000 (2*40500). Unfortunately, the issue remains. This doc doesn’t seem to solve the problem at all.
I wonder what others’ experience with this is and how it can be solved.
OOC, is it normal such major issue to get so little attention here and zero attention on GitHub?
I am just trying to understand whether it is me asking/reporting the wrong way, or is it something already well known to most people, thus others knowing of some useful workarounds, or something else?
Sorry for bothering, it is just too problematic to see windows crashing like that.
imo it isn’t a major issue.
There’s a simple workround - Don’t repeatedly resize windows in this way.
It isn’t restricted to 4k display - it’s repeatable on even basic
displays.
And it’s undoubtedly a symptom of a bug, but it isn’t a major issue - if
it affected many people in normal use it would be a major issue.
I see an issue raised on GitHub.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
It happens even without repeatedly resizing windows. I have seen it even if I resize a window only 2 times in a short time, e.g. if I had tiled the window left instead of right and correcting myself. I also saw it happening while a very short panel widget of sys-net was running in its own small window and simply a terminal window of sys-net was opened, while I was setting some properties of that panel.
Isn’t it major that it is so easy to trigger a (false) OOM error when there are tons of RAM available, resulting in such significant UI issue?
Well this is quite a different report.
And what you are reporting now does not happen for me on a standard
display - perhaps the 4k display has a hand in this.
You’ll need to provide more information about the drivers and hardware.
What makes it different? In my initial message here I mentioned:
“FWIW the system I am testing on has 64 GiB RAM and a 4K desktop.”
In case it is not understood so far, this happens even on a freshly booted Qubes OS, i.e. with only the default (as in default installation) qubes started automatically.
Should I add something to the bug report?
And what you are reporting now does not happen for me on a standard
display - perhaps the 4k display has a hand in this.
It happens to me even when the 4K display is used in 2K (1920x1080) resolution. Doesn’t that exclude the resolution as a factor?
You’ll need to provide more information about the drivers and hardware.
The hardware is a NitroPC with a 4K 10-bit screen connected via DisplayPort.
I also tested with a 8-bit 2K screen connected via HDMI. The result is inconsistent when I start the default terminal emulator/command line for the respective qube:
Disposable: fedora-36-dvm: no issue
Disposable: whonix-ws-16-dvm: no issue
sys-firewall: no issue
sys-net: crashes
sys-usb: crashes
fedora-36: freezes after holding the keyboard shortcut long enough and the interface inside the terminal window becomes unresponsive. It cannot even be closed normally, so one needs to restart the qube to restore normal functionality.