23

Although there are several existing questions on the matter (from which the most helpful answer is this) and various threads on other forums, I cannot reliably set my xrandr settings in Debian 7 on VirtualBox.

I am trying to use xrandr to control my display settings (rather than allowing my desktop environment to automate them) because I am using the i3 window manager, which does not automate display settings or use the Gnome desktop environment display settings.

Setup:

I'm not sure how relevant any of this is, especially the hardware stuff, since I don't think Debian can actually access much info about the monitor setup; as far as I can tell, VirtualBox just reports the existence of virtual screens as if they were hardware monitors.

Hardware

  • Lenovo Laptop with nVidia graphics (the integrated Intel GPU is not used, AFAIK--there's a BIOS setting I used to accomplish this)
    • Windows 7
    • 32GB RAM
    • Using latest (I think) nVidia driver (340.84) -- this might matter, since I enabled 3D acceleration in VirtualBox (see below), which I think allows the guest OS to have access to the host hardware
  • Seiki 4K TV (used as monitor) via HDMI via docking station (which internally converts DisplayPort to HDMI)
  • Samsung SyncMaster 243T monitor turned vertical

VirtualBox

  • Using VirtualBox 4.3.20
  • Guest additions (same version) are installed
  • Monitor count: 2 (assigned to the Seiki and the SyncMaster when in full screen mode)
  • Maximum video memory (128 MB) used
  • 3D Acceleration is enabled

Guest settings

  • 32-bit Debian 7
  • gnome and gdm3 are installed
  • Preferred WM is i3

Behavior:

When I launch i3 and query xrandr, the default display settings always appear to be identical between VBOX0 and VBOX1, the two "monitors" that VirtualBox reports to xrandr (at least, that's how I understand it; I could be missing something). Note that as far as I can tell, there's no good way to tell which VBOX# is which monitor short of trial-and-error.

Usually this includes a reasonable (if slightly below native) resolution for my vertical SyncMaster, but no 4K resolution for the Seiki. The "auto-resize guest display" option in VirtualBox does not appear to affect xrandr.

I have tried various modifications of the script described in the answer linked above, but in general I seem to get various xrandr errors. I have not found many correlations between the various things I've tried and the errors I get, but here are the main things that might be important:

Script tweaks

  • (Usually) skipping the VBoxService restart steps (they do not seem to change the xrandr behavior)
  • Use xrandr --fb option before any other xrandr commands; this sometimes results in "specified screen not large enough" error listed below
  • Use 30 fps instead of 60 (4K via current HDMI is 30fps max, but I don't think this should matter within VirtualBox; in any case I think I've sometimes had it work and sometimes had it fail both ways)
  • Use cvt instead of gtf (these appear to behave essentially the same way)
  • Substitute the first number given by gtf (which is usually around 200 or 300) with a smaller number, such as 100.00 (I think this worked once or twice on the command line, but doesn't generally appear to make a difference)
  • Randomize new mode names using $RANDOM (I've also tried various other means of fiddling with names)
  • Explicitly --rmmode modes before creating them using --newmode (this appears to prevent the "font" error listed below)
  • Use --right-of or --left-of when setting --outputs (since the screens usually are mirrored by default)

Error messages

  • xrandr: specified screen 5120x2160 not large enough for output VBOX0 (3840x2160+3840+0) X Error of failed request: BadValue (integer parameter out of range for operation) I got this one just now when re-running the script after the monitors had already been coerced to their proper resolution (using the work-around described in the next section). This surprised me, because xrandr reports the following: Screen 0: minimum 64 x 64, current 5120 x 2160, maximum 16384 x 16384
  • X Error of failed request: BadMatch (invalid parameter attributes) This sometimes occurs when trying to do a --newmode. It is probably the second most common reason for the script to fail. I think it may be caused by xrandr "remembering" the name of the mode from a previous attempt to set it up, but using $RANDOM does not appear to consistently solve the problem, so it may be some other problem. (I suppose it's possible that even with $RANDOM there are name collisions, though.) I have not seen this error since I started using --rmmode, but I haven't run the script enough times since adding that command to be sure that it's made a difference to the behavior.
  • X Error of failed request: BadMatch (invalid parameter attributes) This sometimes occurs when trying to do an --addmode. It is probably the most common reason for the script to fail, and it mystifies me. Sometimes manually (i.e. in a terminal) executing the same sequence of commands used by the script seems to be a viable workaround for this error, which is bizarre.

Gnome workaround:

I have found that if I log in to the Gnome desktop, then perform VirtualBox's "Auto-resize guest display" function, then log out and back in with i3, xrandr typically includes the correct resolutions for both the Seiki and the SyncMaster in its auto-generated list of modes, and the 4K resolution is set as the "preferred" resolution for each VBOX screen. This allows me to simply use xrandr --output [4K VBOX] --auto --left-of [SyncMaster VBOX], followed by xrandr --output [SyncMaster VBOX] --mode [SyncMaster resolution] (note that the SyncMaster resolution must still be manually specified, since xrandr reports the same preferred resolution for both VBOX#'s with no regard for truth or sanity).

This workaround, once performs, apparently persists across shutdowns and reboots (that is, the desired modes are still present in xrandr's mode list, though I still need to run the two xrandr commands after starting an i3 session), but does not always persist when simply logging out and starting a new i3 session. Note that the gdm3 login screen never has the correct resolution (as far as I have seen). I have no further comment on the strangeness going on here.

EDIT: This approach doesn't seem to be scriptable, and the behavior actually doesn't seem to be consistent.

Other notes:

  • I do not have an xconf (or similar) file in my etc/X11 dir.
  • Fixing the displays is a pretty common problem, because whenever I turn off one of my monitors, VirtualBox kills one of the fullscreen virtual monitors. (Urgh.)

Questions:

  • Is there any way to programmatically distinguish between the actual hardware capabilities (i.e. native resolutions) of different monitors from within VirtualBox?
  • Why am I seeing these various errors? What is going on with xrandr, etc?
  • Is there any way to reliably achieve the right fullscreen resolution without requiring me start a gnome session before my i3 session?

Possibly related issues

  • My mouse pointer does not reliably line up correctly with where clicks appear to be detected; clicks usually occur below and to the right of the pointer. Once I have the screens correctly configured, this problem usually disappears, though currently the screens have the correct resolutions but the pointer is still slightly off.
  • When I do manage to get the resolutions correct, the screen occasionally flickers. This is annoying but livable. Any idea what causes it or if it can be fixed?
Community
  • 1
Kyle Strand
  • 1,916

1 Answers1

0

Updating to the latest VirtualBox version, 5.0.14, appears to have resolved the issue.

Kyle Strand
  • 1,916