Sluggish Display for Manjaro KDE as VirtualBox Guest

kde
virtualbox

#1

I seem to have a similar issue to flatline in Manjaro as virtualbox guest: X11 resolution problems, where I cannot get a Manjaro KDE guest (17.0.5 Gellivara) to detect a framebuffer. My main issue is that the display still feels sluggish (running at 2 fps). hwinfo --framebuffer shows nothing. What am I missing to improve video performance?? Thanks.

I’ve done the following:

  • Installed virtualbox-guest-utils on Manjaro guest
  • In the Windows 7 host, I added extradata for my particular resolution
    > VBoxManage setextradata “Manjaro” “CustomVideoMode1” “1680x1050x32”
    > VBoxManage getextradata “Manjaro” "CustomVideoMode1"
    Value: 1680x1050x32
  • Enabled 3D acceleration in VirtualBox
  • Set the kernel flag GRUB_CMDLINE_LINUX_DEFAULT to video=1680x1050
  • Rebooted Manjaro

#2

Have you tried 2D accelleration in VBox?

Did you install the VirtualBox Extensions? These can be installed directly from inside Virtualbox on the preferences menu. They include video drivers, among other things,

Also from that same Preferences page in Virtual box, you can set Maximum Guest Screen Size to automatic rather than a fixed size.

Also did you install the Guest Additions iso (which is installed on the host but used by the guest).

Is there a particular reason you want to use Framebuffer? Its way slower than installing the Virtualbox extensions.

Is there a particular reason you want to force a 1680x1050 screen size? Because Vbox was designed to provide a dynamic screen size, allowing you to resize the Virtual Machine’s display as you wish in real-time by just dragging it bigger or smaller as you wish.

None of my Vbox VMs use frame buffer.


#3

With a Manjaro guest, I wouldn’t use any of framebuffer or 3D. Works best in 2D mode with the included guest driver modules.
I have the same question as jsamyth: why do you want to use framebuffer?

With i3 and its notorious window resizing bug, a fixed size could actually better than dynamic auto adjusting.
Make sure your VBox expansion pack is up to date.


#4

Have you tried 2D accelleration in VBox?

VBox says this doesn’t work with Linux guests (only WIndows), and then automatically disables it. I tried it anyways, and it doesn’t affect anything (since it’s probably disabled).

With a Manjaro guest, I wouldn’t use any of framebuffer or 3D. Works best in 2D mode with the included guest driver modules.

The Manjaro wiki recommends enabling 3D for transparency (KDE Plasma definitely uses it). Although, I will try to disable 3D now to see if it helps with 2D performance… no dice, didn’t seem to help.

Did you install the VirtualBox Extensions? These can be installed directly from inside Virtualbox on the preferences menu. They include video drivers, among other things,

Yes, I’ve installed this, and it’s the same version as VBox.

Also did you install the Guest Additions iso (which is installed on the host but used by the guest).

I installed the package virtualbox-guest-utils, or maybe it was installed by default as the Manjaro wiki seems to indicate? Either way, it’s installed. I read that this is the same thing. Is that not true? The utilities seem to be loaded in SystemD:

...
       │     ├─ 498 /usr/bin/VBoxClient --clipboard
       │     ├─ 499 /usr/bin/VBoxClient --clipboard
       │     ├─ 506 /usr/bin/VBoxClient --display
       │     ├─ 507 /usr/bin/VBoxClient --display
       │     ├─ 516 /usr/bin/VBoxClient --seamless
       │     ├─ 517 /usr/bin/VBoxClient --seamless
       │     ├─ 521 /usr/bin/VBoxClient --draganddrop
       │     ├─ 522 /usr/bin/VBoxClient --draganddrop
...

Is there a particular reason you want to use Framebuffer? Its way slower than installing the Virtualbox extensions.

I have the same question as jsamyth: why do you want to use framebuffer?

This is part of the installation steps for VirtualBox guests on the Arch Wiki. They give the following reasoning for doing this:

Typically after installing Guest Additions, a fullscreen Arch guest running X will be set to the optimal resolution for your display; however, the virtual console’s framebuffer will be set to a standard, often smaller, resolution detected from VirtualBox’s custom VESA driver.
To use the virtual consoles at optimal resolution, Arch needs to recognize that resolution as valid, which in turn requires VirtualBox to pass this information along to the guest OS.

If it won’t help, then I won’t bother working with a framebuffer. However, the slow 2D rendering still remains… any other ideas? Thanks for the help, btw.


#5

If there’s no solution, then can someone please tell me if you have a working VirtualBox Manjaro guest running with a decent framerate, so I know if it’s just my machine?


#6

It is not just your machine, I have noticed this too on multiple host systems, but only since the latest virtualbox update to 5.1.28. Happens with both 4.9LTS and 4.13 kernels. Not sure why either.

EDIT :

Nobody else experiencing very laggy graphics in Manjaro guest VM after the upgratde to 5.1.28? I have an unstable and test VM and both are extremely laggy, no logs to indicate why.


#7

I have a manjaro kde system (unstable branche) as guest on my windows 7 machine at work… and it works perfectly.
guest is running on kernel 4.9 and in dual screen mode with 3D acceleration ON

of course the virtual console (TTY) don’t have a fixed resolution corresponding to my screen as I don’t care. why to create a frame buffer that will need more RAM for virtual console I never use… :wink:


#8

I never did try to downgrade, but then again, nothing in the changelog seems to affect the Linux X windows system:

VirtualBox 5.1.28 (released 2017-09-13)

This is a maintenance release. The following items were fixed and/or added:

GUI: mouse events did not reach host windows behind the transparent VM window (Mac OS X hosts only; bug > #16246)
Audio: fixed accidental crashes when using the AC’97 sound emulation (bug #16959)
Audio: fixed crash when default input or output devices have changed (bugs #16968, #16969, #17004)
Audio: fixed recording when using the ALSA backend
Audio: fixed handle leak when using the OSS backend
E1000: fixed a crash related to VLAN traffic over internal network (5.1.26 regression; bug #16960)
NAT: apply --natbindip1 to TCP connections (bug #16478)
OVF: when importing an appliance with XHCI controller, don’t add an OHCI controller.
Mac OS X hosts: fixed a GUI crash if Spotlight is used from file dialogs (5.1.20 regression; bugs #16935, #16953)
Linux hosts: fixed creating fixed sized VDI images (bug #17010)
Linux hosts / guests: fixes for Linux 4.4 of openSUSE Leap 42.3 (bug #16966)
Bridged networking: align outgoing packet at word boundary, preventing Windows host crash in MsLbfoProvider.
Linux Additions: kernel drm driver support for custom EL7 Linux 3.10 kernel
Solaris Additions: hide an informational message on the bootup console

The first entry in the changelog, although unrelated to Linux, did get me thinking, though… the flavor of Linux I select when setting up the VM may be affecting the performance. I am selecting Arch Linux, since Manjaro is based in Arch, but would selecting a generic Linux or something else affect the 2D performance? I think this combobox selection only selects expected RAM/display memory, but it could also load different drivers (just my speculation).

That’s great that you have a dual monitor Manjaro install running smoothly. Could you please verify what OS you selected in the Virtualbox host? Is it Arch Linux or something else? Regarding the framebuffer for TTY, I guess I was just following the guide without thinking too deeply about it. Turns out, it’s pretty useless when booting into a GUI. :slight_smile:


#10

You could be messing around and wasting your time as described earlier in topic OR just install Manjaro XFCE, it works great without any hassle. It’s IMO the best option.


#11

I will definitely try XFCE (stable) to see if that solves the issue, thanks. I assumed it was a general X windows issue.

Even still, I’d like to get KDE working if at all possible. I really like KDE. :slight_smile: It seems like there are a few things to try:

  • Downgrade VirtualBox
  • Install KDE unstable
  • Install XFCE stable

#12

I don’t think it comes from the branche, my system was installed month ago (More than 6 month) and always worked fine.
it’s sure my work computer is not a bad one. It’s a core i7 4770 3.4GHz (8 virtual core) with nVidia NVS 310 . I set 4 virtual core and 2.5GB RAM for my VM.

I won’t be able to be sure before monday when I will be at work, but I’m alsmost sure I choosed Arch linux system when I created the VM.

EDIT: I confirm it’s set as arch linux 64bits.
here is my settings:


#13


I switched over to KDE unstable, upped the video memory to 64MB, used 2 processors instead of 1. These appear to have made my KDE much more snappy. Thanks, scachemaille!