VirtualBox

Ticket #19873 (new defect)

Opened 14 months ago

Last modified 12 months ago

VMSVGA: 1920x1080 resolution not available at boot (?)

Reported by: alealeale Owned by:
Component: guest additions/x11/graphics Version: VirtualBox 6.1.14
Keywords: 1920x1080 login Cc:
Guest type: Linux Host type: Windows

Description

As I've reported in some other tickets, I have a Oracle Linux Server release 7.8 VM running on Windows 10.
The Video Memory is set to 128MB and the Graphics Controller to VMSVGA.
The VM starts in Full-screen Mode on my second display which is set to 1920x1080.

After upgrading from 6.1.6 to 6.1.10 (I've skipped 6.1.8) I have the following problem: the greeter (lightdm) doesn't span the whole maximized VM window because the resolution is lower, but that should not be the problem, as far as I can remember this always happened on the first display of the greeter after boot.
But after logging in the screen remains black with a visible mouse cursor instead of displaying my desktop at 1920x1080.

The workaround I'm using is sending the guest into runlevel 3 and then again into runlevel 5 so Xorg gets restarted and after doing that I can login successfully into my desktop at the desired resolution.
So I tool a look at Xorg.0.log soon after boot and then after the telinit workaround.
I think that the relevant differences are:

94c94
<  (II) vmware(0): Modeline "800x600"x60.0   42.75  800 850 900 950  600 650 700 750 -hsync +vsync (45.0 kHz eP)
---
>  (II) vmware(0): Modeline "1920x1080"x60.0  152.77  1920 1970 2020 2070  1080 1130 1180 1230 -hsync +vsync (73.8 kHz eP)
129c129
<  (II) vmware(0): Output Virtual1 using initial mode 800x600 +0+0
---
>  (II) vmware(0): Output Virtual1 using initial mode 1920x1080 +0+0

So it seems that 800x600 is available soon after boot while 1920x1080 is not and, after restarting Xorg, the other way around.
I've tried with Acceleration enabled and disabiled with the same result.

I also tried with VBOXSVGA but it has far more Modeline than VMSVGA, including 1920x1080, so there is no such problem with in this case.

P.S.
I don't know if it's something related to the problem, since I moved to 6.1 and switched to VMSVGA if missing with the following two commands (see also Ticket #19392), but it seems they aren't working anymore:

VBoxManage.exe setextradata ''<vmname>'' CustomVideoMode1 1920x1080x32
VBoxManage controlvm ''<vmname>'' setvideomodehint 1920 1080 32

anyway the screen was set to the higher resolution available after login and not black.

Attachments

vmsvga.before-Xorg.0.log Download (18.0 KB) - added by alealeale 14 months ago.
Xorg.0.log after boot
vmsvga.after-Xorg.0.log Download (18.0 KB) - added by alealeale 14 months ago.
Xorg.0.log after switch to runlevel 3 and then back to 5
vboxsvga-Xorg.0.log Download (19.9 KB) - added by alealeale 14 months ago.
Xorg.0.log at boot using vboxsvga
VBox.zip Download (36.9 KB) - added by alealeale 13 months ago.
Xorg.0.log.xz Download (4.4 KB) - added by alealeale 13 months ago.

Change History

Changed 14 months ago by alealeale

Xorg.0.log after boot

Changed 14 months ago by alealeale

Xorg.0.log after switch to runlevel 3 and then back to 5

Changed 14 months ago by alealeale

Xorg.0.log at boot using vboxsvga

comment:1 Changed 14 months ago by alealeale

I tried reinstalling the Guest Additions from VBoxGuestAdditions_6.1.6.iso and 1920x1080 Modeline is still missing on Xorg.0.log soon after boot.

Anyway that should not be the problem, because after logging in I can see my desktop at 1920x1080.

Please let me know any other test I can do or any other info I can collect to better understand this problem.

Last edited 14 months ago by alealeale (previous) (diff)

comment:2 Changed 14 months ago by alealeale

I did some tests with different versions of the Guest Additions.
The problem exists since 6.1.8.

A curious thing I noticed is that the problem doesn't appear restarting the VM:
shutdown -r now->login->desktop @1920x1080
shutdown -h now->start VM from Manager->login->black screen

comment:3 Changed 13 months ago by alealeale

I think I've solved the problem clearing the GUI/LastGuestSizeHint (before: Value: 1280,1019; after: No value set!), hint I've never manually set.

Sorry, I was wrong.
That doesn't fix the issue.

What I've noticed is that if I switch to another virtual console (ctrl+alt+f2) while the screen is black and than back to the one where X is running (ctrl+alt+f1) the desktop is visible again.

Last edited 13 months ago by alealeale (previous) (diff)

comment:4 Changed 13 months ago by alealeale

I'm sending a VBox.log.

I wrote down the starting and ending line numbers of some steps:
1) 1-1572 - boot to login
2) 1573-1778 - do login => black screen
3) 1779-1784 - switch to tty2
4) 1785-1790 - switch to tty1 => desktop visibile
5) 1791-3038 - shutdown and that's what I've noticed...

In step 2 (when the screen become black), there are some lines with Display::i_handleDisplayResize and the last one @1774 is:

Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000000000000 w=1920 h=1080 bpp=0 cbLine=0x0 flags=0x2 origin=0,0

with bpp=0; is that the reason why the screen become black?
Just 5 lines before it was set to the correct resolution and in fact the screen "flashes" before becoming black.

In step 4 (when the desktop become visible) there are 2 lines with Display::i_handleDisplayResize and the last one @1786 is:

Display::i_handleDisplayResize: uScreenId=0 pvVRAM=000000000fef0000 w=1920 h=1080 bpp=32 cbLine=0x1E00 flags=0x1 origin=0,0

with bpp=32, which looks more reasonable to me.

Version 1, edited 13 months ago by alealeale (previous) (next) (diff)

Changed 13 months ago by alealeale

Changed 13 months ago by alealeale

comment:5 Changed 13 months ago by alealeale

I've just added Xorg.0.log as attachment.

comment:6 Changed 12 months ago by arQon

I have the same bug, but I'm not sure I agree with the diagnosis so far. I think the ticket is also being needlessly complicated by the OP's reference to a second display, which is irrelevant: a guest set to start in fullscreen simply never renders anything except the cursor, regardless of which monitor it's on.

@alealeale - the i_handleDisplayResize calls appear to be for accelerated displays only, as they aren't present in the X log here. When requesting a GL context, bpp=0 just means "whatever depth/stride the driver prefers", and since it's doing so at a time that pvVRAM is null, that looks like a first request and it seems eminently reasonable for bpp to be 0 in that case. But I'm not familiar with the code, so feel free to take that opinion for what it is. :)

What I can say, with reasonable confidence, is that the absence of the correct modeline seems to be irrelevant, as I have the

[    12.847] (II) vmware(0): Modeline "1920x1200"x59.9  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync (74.6 kHz e)

needed for my display to function correctly, but the screen is still blank on VM start until a repaint is forced via VT switch or fullscreen toggle etc.

Last edited 12 months ago by arQon (previous) (diff)

comment:7 Changed 12 months ago by alealeale

I read in the forum that someone facing the same problem had it solved after upgrading to 6.1.16, reporting this entry in changelog as the (supposed?) solution: [i]Linux guest: Workaround to improve resizing of 32-bit VMs with VMSVGA graphics controlleri That's not my case and maybe it should not as I'm not on 32-bit. Do we have the same problem on 64-bit but still waiting for a fix?

@arQon What I wrote here was not meant to be a diagnosis. :) I just tried to describe the more accurately what's happeing to me and to report everything seems relevant to me testing every addictions version since 6.1.6 and collecting various logs and tracing the lines at every step, which took some time to me. I'm "happy" that someone can add more hits to help identifying the problem. For sure I was wrong about the bpp=0 and after your contribution it seems that also about the Modeline. It seems that you are facing the same problem...does it works as expected for you also after a VM reboot (not shudown + start)? That's something I really can't understand...

comment:8 Changed 12 months ago by arQon

@alealeale - sorry if that sounded like i was blaming you! You are absolutely correct to have provided as much information as you could: I was just updating the ticket to make it clear that the second screen (which is a source of problems in its own right) isn't relevant, so that the devs know there's a more fundamental repro path.

re: rebooting a VM, yes, I see the same behavior. It makes sense to me that that's potentially different: since the bug is rooted in resize+repaint problems, and a sizeable amount of state persists in the VM instance across guest reboots (in some ways, a reboot is basically meaningless to a substantial part of a VM), it's very understandable that an initialization bug would be a once-only event across the lifetime of the VM instance itself.

Do we have the same problem on 64-bit but still waiting for a fix?

I think that's how I would read it too, yes. I'm just surprised the x64 fix wasn't the first one. Still, it's promising at least. :)

comment:9 Changed 12 months ago by arQon

@devs - as expected,

xrandr --size 1920x1440
xrandr --size 1920x1200

in a DE startup script brute-forces through the bug and causes the initial render to actually happen.

comment:10 Changed 12 months ago by arQon

@alealeale - your logs suggest you're trying to use EFI, correct? If so, could you try

VBoxManage setextradata <VM> VBoxInternal2/EfiGraphicsResolution 1920x1080

and see if that helps at all? (Note that you'll need to disable the script hack if you've got that in place already!).

I wouldn't put money on it, but since you get a visible DM already I think it's at least got a chance. Either way, let the devs know here. Thanks.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use