Bug 26872 - When setting up a Vbox client VBoxVGA is not selectable
Summary: When setting up a Vbox client VBoxVGA is not selectable
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-29 23:09 CEST by William Kenney
Modified: 2020-07-01 11:50 CEST (History)
4 users (show)

See Also:
Source RPM: virtualbox
CVE:
Status comment:


Attachments

Description William Kenney 2020-06-29 23:09:54 CEST
Description of problem:

Mageia 8, x86_64, Plasma DE
Vbox 6.1
When setting up a Vbox client Settings -> Display -> Graphics Controller
The default setting is VMSVGA. When you attempt to change that to VBoxVGA
and then click ok the new setting does not stick and reverts back to VMSVGA.
Comment 1 Lewis Smith 2020-06-30 20:21:14 CEST
Thank you for the report, Bill.

Assigning to the kernel team because that is where Vbox bugs used to go. If this is wrong, please re-assign it; I am keeping an eye on the bug to find out.

Assignee: bugsquad => kernel
CC: (none) => lewyssmith

Comment 2 Pascal Terjan 2020-06-30 23:23:58 CEST
I don't know much about virtualbox but a quick search tells me they want you to use VMSVGA...

In the changes of 6.1.0:

Graphics: New style 3D support (with VBoxSVGA and VMSVGA) remains, old style 3D support (with VBoxVGA) has been completely removed

People in forums also say the can no longer boot their VMs which were using VBoxVGA unless they disable acceleration (which makes sense given than VBoxVGA no longer supports acceleration).

CC: (none) => pterjan

Comment 3 Pascal Terjan 2020-06-30 23:26:55 CEST
https://www.virtualbox.org/manual/ch03.html#settings-screen

VBoxSVGA: The default graphics controller for new VMs that use Windows 7 or later.

This graphics controller improves performance and 3D support when compared to the legacy VBoxVGA option.

VBoxVGA: Use this graphics controller for legacy guest OSes. This is the default graphics controller for Windows versions before Windows 7 and for Oracle Solaris.

3D acceleration is not supported for this graphics controller.

VMSVGA: Use this graphics controller to emulate a VMware SVGA graphics device. This is the default graphics controller for Linux guests.
Comment 4 William Kenney 2020-06-30 23:43:42 CEST
(In reply to Pascal Terjan from comment #3)
> https://www.virtualbox.org/manual/ch03.html#settings-screen
> 
> VBoxSVGA: The default graphics controller for new VMs that use Windows 7 or
> later.
> 
> This graphics controller improves performance and 3D support when compared
> to the legacy VBoxVGA option.
> 
> VBoxVGA: Use this graphics controller for legacy guest OSes. This is the
> default graphics controller for Windows versions before Windows 7 and for
> Oracle Solaris.
> 
> 3D acceleration is not supported for this graphics controller.
> 
> VMSVGA: Use this graphics controller to emulate a VMware SVGA graphics
> device. This is the default graphics controller for Linux guests.

Interesting comment as VBoxVGA was the preferred for Vbox M7 installs.
I agree that VMSVGA seems to run just fine here on my M8 Vbox install.
Thierry Vignaud 2020-07-01 00:27:35 CEST

CC: (none) => thierry.vignaud
Source RPM: (none) => virtualbox

Comment 5 Giuseppe Ghibò 2020-07-01 01:53:14 CEST
A few extra notes. As pascal said: VBoxSVGA is for Windows 7 and beyond.

- VBoxVGA actually do not provide hardware 3D acceleration, though it has 3D support. Basically with this card enabled, the kernel driver used is "vboxvideo", the VGA card emulated is described as "VGA compatible controller", with product "VirtualBox Graphics Adapter" and vendor "InnoTek Systemberatung GmbH". Mageia configure it to use X11 with the kernel "modesetting" driver. The 3D OpenGL is achieved using "llvmpipe" driver of mesa, and the OpenGL compatibility level exposed is 3.3. This either checking or unchecking the VBoxClient 3D box. Starting from VirtualBox 6.1.X, this 3D box option is no longer selectable, though it may appear sometimes selected, e.g. have inherited from older VirtualBox 6.0 machines, or by manually editing the VirtualBox configuration files. In the past the 3D acceleration with this card was achieved with the "Chromium" mesa driver IIRC, though it wasn't much stable, crashed often and had poor OpenGL compatibility level. As for performance on a tipical core i7 6xxx, llvmpipe can have a glmark2 score of 300 or 400.

 
- VMSVGA. This uses the vmware card emulation, that was initially developed for vmware. Without its 3D checkbox enabled, the 3D is the same as for VBoxVGA, i.e. with software "llvmpipe", with the same feature listed before (e.g. OpenGL level 3.3). The VGA card is described as "VGA compatible controller", with product id "SVGA II adapter" and vendor id "VMware". Mageia configure X11 with this card with driver "vmware". The kernel driver module for this card is "vmwgfx", which for kernel 5.7.X is at version 2.17.0.0.

VMWSVGA+3D checkbox enabled. Same as before but used 3D acceleration through the vmwgfx interface. Mageia configures as "vmware" X11 driver, the DRI acceleration uses the vmwgfx_dri and the kernel vmwgfx module (2.17.0.0). With this enabled the 3D is "hardware" accelerated. Performance can reach a score of 1700-2000 with glmark2 (on a core i7 with Intel 530 graphics card, where native glmark2 score is around 3800-4000), so tipically  5-10 times faster than llvmpipe. The OpenGL level exposed is fewer than "llvmpipe", and is "just" 2.1. In theory OpenGL levels of 3.3 or 4.1 should be exposed with a recent version of mesa,  though I've not yet found how to enable it: apparently for achieving higher OpenGL compatibility levels (beyond support from mesa), this needs that dmesg shows the string: "[drm] DX: yes".  But I always get it to "[drm] DX: no". Dunno how to achieve "DX: yes", probably it's needed a newer vmwgfx driver. It seems that there is already vmwgfx kernel driver 2.18 and beyond, though I've not yet understand where to derive/backport from. Actually this is getting better and better over the releases.

A bug that should be reviewed and be paid attention to, that we hit, but that it should be already fixed on mageia is:

https://bugzilla.redhat.com/show_bug.cgi?id=1789545

in particular for whether we pass the "--vmsvga" option in the VBoxClient for the virtualbox additions. Also to be reviewed, the VBoxDRMClient permission (suid or not).

CC: (none) => ghibomgx

Comment 6 William Kenney 2020-07-01 01:59:23 CEST
Thanks to everyones efforts on this.
Maybe we should put a short summary of this in the M8 errata.
Comment 7 Giuseppe Ghibò 2020-07-01 11:20:13 CEST
IMHO we need to place some extra info in a common wiki page, with some short reminder from the errata.

BTW, there is still another glitch. Starting from around VBox 5.2.30 the sound with HDAUDIO (though apparently HDAUDIO is superior to AC97) is not working correctly anymore. It scratches and jitter during a playback. Reverting to AC97 AUDIO works flawlessly. This can be done manually in Settings/Audio/AudioController => choose AC97 audio.

Newer machines created using the default wizard for mageia have the audio selected to HDAUDIO. I think this should be reverted to AC97. Actually we use the  patch here:

http://svnweb.mageia.org/packages/cauldron/virtualbox/current/SOURCES/VirtualBox-6.1.8-add-Mageia-support.patch?revision=1584769&view=markup

and we should revert AudioControllerType_HDA for the mageia section to AudioControllerType_AC97 (like other distros) in the mageia choice (OK, that's another bug). In this way newer mageia machines will be created with the audio default setting to AC97 controller.
Comment 8 Lewis Smith 2020-07-01 11:50:51 CEST
Thank you everyone for all the learned comments.

Going right back to comment 0, and considering all the wisdom expressed in this bug, it looks to me as if Mageia 8's behaviour is good, and we could close this 'invalid' - no offence, Bill.
The idea of a Wiki is not bad, with a pointer to it in Release Notes (not Errata).

Re comment 7 & sound, it looks as if our Cauldron VBox client 
"should revert AudioControllerType_HDA for the mageia section to AudioControllerType_AC97 (like other distros) in the mageia choice (OK, that's another bug). In this way newer mageia machines will be created with the audio default setting to AC97 controller".
Can this be done without a new bug? This is, after all, Cauldron; implicitly always evolving.

Note You need to log in before you can comment on or make changes to this bug.