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.
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.
- 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
- 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
- 32-bit Debian 7
- Preferred WM is
When I launch
i3 and query
xrandr, the default display settings always appear to be identical between
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
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:
- (Usually) skipping the
VBoxServicerestart steps (they do not seem to change the
xrandr --fboption before any other
xrandrcommands; 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)
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)
--rmmodemodes before creating them using
--newmode(this appears to prevent the "font" error listed below)
--outputs (since the screens usually are mirrored by default)
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
xrandrreports 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
$RANDOMdoes not appear to consistently solve the problem, so it may be some other problem. (I suppose it's possible that even with
$RANDOMthere 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.
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
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.
- I do not have an
xconf(or similar) file in my
- 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.)
- 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
- Is there any way to reliably achieve the right fullscreen resolution without requiring me start a
gnomesession before my
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?