Debian – Cannot reliably automate xrandr settings in Debian 7 on VirtualBox

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?