ZaphodHeads output ordering does not work with vboxvideo

[zboszor]

Hi!

We use dual screen with Xorg set up with separate "DISPLAY=:0" and "DISPLAY=:0.1" screens for independent fullscreen applications.
To account for monitor deployments and local wishes, the order of outputs is configurable.

This works on real hardware (tested on AMD and Intel drivers) but fails on VirtualBox with a VM configured for two monitors with VBoxSVGA when the order or screens does not match the order of virtual outputs.

Attached is the example Xorg configuration file that works, i.e. VGA-1 is screen 0, VGA-2 is screen 1.

EDIT: tested with two OS versions in two VMs: one with kernel 5.2.17 + Xorg 1.19.3, another with kernel 5.7.7 + Xorg 1.20.8. Both work or fail the same way.

Code: Select all

$ rpm -qa "VirtualBox*"
VirtualBox-6.1-6.1.10_138449_fedora32-1.x86_64

[zboszor]

Here's the reversed configuration that fails: VGA-2 is screen 0, VGA-1 is screen 1.

[zboszor]

Attached is the Xorg.0.log file from the failure. Both modeset(0) and modeset(1) reports "No modes" and Xorg gives up.

[scottgus1]

Are you running ZaphodHeads inside the guest OS or on the host PC?

If on the host PC, Virtualbox's VMs don't see the physical hardware, only the simulated 'hardware' that Virtualbox provides. So the guest OS is not going to know what Beeblebrox's two heads are telling the host hardware.

Always try to think of the VM as a separate physical PC, then look for a solution that might influence a separate PC.

What does ZaphodHeads actually do beyond what a regular OS does with multiple monitors, and how do you want multi-monitor Virtualbox guests to perform?

[zboszor]

The quoted Xorg configuration files (i.e. the ZaphodHeads setup) are in the guest.

The intended use case is this below, i.e. have two independent X screens for two independent applications both running fullscreen with their own fvwm or matchbox-wm window managers.

Code: Select all

[root@localhost ~]# DISPLAY=:0 xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 16384 x 16384
VGA-1 connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1440x900      59.99*+  59.89    59.89    59.90  
   2560x1600     59.99    59.97  
   1920x1440     60.00  
   1856x1392     60.00  
   1792x1344     60.00  
   2048x1152     60.00  
   1920x1200     59.88    59.95  
   1920x1080     59.96    60.00  
   1600x1200     60.00  
   1680x1050     59.95    59.88  
   1400x1050     59.98    59.95  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1366x768      59.79    60.00  
   1360x768      60.02  
   1280x800      59.81    59.91  
   1280x768      59.87    59.99  
   1280x720      59.86    60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   848x480       60.00  
   640x480       59.94  
[root@localhost ~]# DISPLAY=:0.1 xrandr
Screen 1: minimum 320 x 200, current 1440 x 900, maximum 16384 x 16384
VGA-2 connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1440x900      59.99*+  59.89    59.89    59.90  
   2560x1600     59.99    59.97  
   1920x1440     60.00  
   1856x1392     60.00  
   1792x1344     60.00  
   2048x1152     60.00  
   1920x1200     59.88    59.95  
   1920x1080     59.96    60.00  
   1600x1200     60.00  
   1680x1050     59.95    59.88  
   1400x1050     59.98    59.95  
   1600x900      60.00  
   1280x1024     60.02  
   1280x960      60.00  
   1366x768      59.79    60.00  
   1360x768      60.02  
   1280x800      59.81    59.91  
   1280x768      59.87    59.99  
   1280x720      59.86    60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   848x480       60.00  
   640x480       59.94  

Reversing the roles of VGA-1 and VGA-2 through ZaphodHeads fails in the VM guest.
Running Xorg with the (almost) identical configuration files on real hardware works with both ZaphodHeads order, just the output names should be different, i.e. DP-1 and HDMI-1 instead of VGA-1 and VGA-2 as for the VM guest.

[zboszor]

What does ZaphodHeads actually do beyond what a regular OS does with multiple monitors, and how do you want multi-monitor Virtualbox guests to perform?

ZaphodHeads binds one or more hardware outputs to an Xorg Device section in the configuration.
Multiple Device sections are allowed to be used later as a Device or GPUDevice entry in a Screen section of the same configuration file.
Multiple Screen sections can be used (read the example configuration please) in a ServerLayout section to form separate screens.
A GPUDevice entry for a Screen section allows using acceleration on dumb devices, i.e. use an USB DisplayLink device as framebuffer Device but back it with GPUDevice that provides acceleration.

Since the VirtualBox guest is supposed to work like real hardware, it can be expected that it also works with different ZaphodHeads configuration setups.

I also noticed another issue, the second head of the VM guest is not always updated properly. On OSX hosts, I have to click into the window on the host to get it updated, on Fedora 32 hosts I have to resize the second window to have it updated.

[scottgus1]

I have spent a little time trying to wrap my brain around ZaphodHeads, but I am unable to do so. Either the program itself or the explanation thereof is at least a second head's distance above my head, or I'd need three arms to try to hold it down. OK, no more HGTTG references...

As I gather it, ZaphodHeads helps Linux X figure out how to use a single video card with multiple video outs as multiple different monitors, perhaps appearing as multiple video cards to the X server, making configuration easier. It might also break up a large monitor to appear as multiple smaller monitors?

And I take it you're trying to run ZaphodHeads inside a Virtualbox guest, on the Virtualbox video card.

Unfortunately that's all I can gather about it, and I'm nowhere close to being able to tell how to configure it. FWIW there's only one result when I web-search "zaphodheads site:forums.virtualbox.org", and it's this thread.

We'll have to wait for someone else to weigh in, or look for a different solution.