Created attachment 1383124 [details] journalctl log I am using Fedora WS Rawhide (up-to-date as of 2018-01-19) in a Virtualbox VM running on a macOS 10.13.2 host, with GNOME Desktop on X11. I did not install the Virtualbox kernel module. I can adjust the resolution by resizing the window thanks to the new built-in Virtualbox guest driver in Linux. The issue is that when I switch the window to full screen with the macOS green button, the screen becomes shows graphical corruption (glitches). Unmaximizing the window makes it return to its normal state and it works normally. You can manually resize the window to cover the whole screen and it will work normally. This issue just happens when using full screen. The issue is not present with text TTYs (though they don't scale to full screen even if I maximize the window). Even the default gdm login screen will glitch when in full screen. I can reproduce this issue reliably every time. My kernel is "Linux 4.15.0-0.rc8.git0.1.fc28.x86_64 #1 SMP Mon Jan 15 17:04:36 UTC 2018 x86_64 GNU/Linux" I'm attaching the output from journalctl when displaying the graphical issues.
Thank you for the bug report, I've send a mail to virtualbox upstream about this. You say this happens every time you go fullscreen? I can reproduce this when going fullscreen on a Linux host, but only sometimes. Also can you try going fullscreen using the hostkey (right ctrl on Linux hosts) + F and try toggling fullscreen mode a couple of times ? For me this problem only happens sometimes.
Hans, I've tried to go fullscreen by using the Host+F key combo, and it seems not to make a difference. I've tried various times, both this way and with the maximize button, and the issue can be reproduced really each time. There were differently-shaped visual artifacts through my various attempts, sometimes the glitches happen on a portion of the screen the size of the previous resolution (in windows mode), other times they cover the whole screen. Still I couldn't pinpoint which type is triggered by which action (button vs keypress). I noticed that the bug is only present when the "Auto-resize Guest Display" option is enabled, that is: - if you have it enabled, going full screen will result in glitches, when the intended result is to have it to work (of course) *and* to have it cover the whole screen - if you have it disabled, going full screen will work as intended, meaning that the Virtualbox application will take the whole screen, while the guest display is not resized from its resolution prior to hitting Host+F
I've done quite a bit of testing with regard to this issue and I found out that: 1) It is not directly related to full-screen mode 2) It is related to the guest resolution In fact, the glitches happen regardless of windowed/full-screen mode (read: in both modes), only in consideration of the guest display resolution. 3) It is not related to the desktop environment in use, I tried both GNOME and KDE Plasma with the same overall results 4) It is related to the video memory allocated to the guest In fact letting the guest run with as little as 17/18 MB of video memory (I tried with 16 MB before) makes it not to display those glitches. What strikes me as to why this could possibly be a bug anyway, and not just glitches appearing because of not enough video memory, is the fact that I am able to use other guests, e.g. a Fedora 26 one, on this same host without any problem in the same conditions. Here's the full extent of the tests I've carried out: GUEST #1 CONFIGURATION macOS 10.13.3 (17D47) host Virtualbox 5.2.6 r120293 (Qt5.6.3) No 3D acceleration No 2D acceleration Fedora Rawhide compose 20180123.n.1 Linux 4.15.0-0.rc9.git0.1.fc28.x86_64 gnome-shell-3.27.1-4.fc28.x86_64 plasma-desktop 5.11.95-1.fc28.x86_64 kf5-plasma 5.42.0-1.fc28.x86_64 Resolution / Video memory / issues 2560x1440 16 MB -> glitches/not responsive 2560x1600 16 MB -> glitches/not responsive 2560x1600 17 MB -> glitches/not responsive 1920x1440 16 MB -> no issues 2488x1374 16 MB -> no issues 2560x1440 24 MB -> no issues 2560x1440 18 MB -> no issues 2560x1440 17 MB -> no issues 2560x1600 18 MB -> no issues GUEST #2 CONFIGURATION macOS 10.13.3 (17D47) host Virtualbox 5.2.6 r120293 (Qt5.6.3) No 3D acceleration No 2D acceleration Fedora 26 x86_64 as installed from gold media Linux 4.11.8-300.fc26.x86_64 VirtualBox-guest-additions.5.1.30-2.fc26.x86_64 from rpmfusion-free-updates gnome-shell 3.24.3-2.fc26.x86_64 Resolution / Video memory / issues 2560x1440 16 MB -> no issues
Sergio, are you still seeing this? AFAIK all issues related to video-resolution changes in vbox have resolved for a while now. If you are no longer seeing this, please close this bug.
I've tried again, this time with Virtualbox 6.1.16 and Fedora-Rawhide-20210112.n.0 I'm seeing no glitches anymore, only that with higher resolutions you need more Video memory (default is set to 16 MB in Virtualbox, and this is too low for e.g. 2560x1440) or you get a black screen (which you can recover from by resizing the window to a smaller size). I'm closing this bug.
Yes, I have asked the upstream vboxdevs to increase the default vram size, but I don't think they ever did that. They did switch the default from vboxvideo to vmwgfx a while ago though, so maybe they did increase the vram size when they did that? I did not check. If you feel like it you could check if the vramsize is still an issue when you create a new vm with the latest virtualbox and if it is file an issue upstream?
The defaults for a new Linux guest (Fedora, 64 bit) in latest Virtualbox (6.1.16) are 16 MB video memory and VMSVGA. This is the upstream bug: https://www.virtualbox.org/ticket/19763 (I searched and it was already filed) This one is also relevant: https://www.virtualbox.org/ticket/19732