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?

Kyle Strand

Posted 2015-02-12T02:17:21.247

Reputation: 1 206

I'll need to dig up my notes but what's the supported modes for your displays? does i3 have some way to start a script before/right after login? http://superuser.com/questions/808737/setting-and-keeping-resolution-settings-for-a-display-thats-not-autodetected-on is what I ended up doing with a similar, physical issue, but this may need a bit of finassing to work in your case.

– Journeyman Geek – 2015-04-08T03:34:07.123

@JourneymanGeek The 4K has support for most of the standard modes at 60 hz, and support for larger modes (including 4K) at 30 hz. The SyncMaster appears to support most of the normal modes, with a native (vertical) resolution of 1920x1280. The i3 config script does support running a script at login; I'm using this feature to automatically run the script described above, which looks similar to yours, but I keep getting weird xrandr errors. – Kyle Strand – 2015-04-08T16:03:13.967

How do you launch i3? Does it have its own X initialization routine? Or do you drop it in your .xinitrc and use startx? I use xmonad (which, as I understand, is similar to i3?) which I launch using startx. My xrandr scripting is all done in .xinit just before my window manager is launched. I've had excellent results that way. X is ready to go, and nothing else has launched to interfere. – Chris – 2015-04-09T01:17:49.087

I use gdm3 and have i3 selected as the default desktop environment for my account. – Kyle Strand – 2015-04-09T02:28:06.410

Sorry, not sure how I missed that. Have you tried injecting the xrandr commands directly in the gdm startup scripts? (/etc/gdm/* according to the Arch Wiki) Although I'm not sure how helpful that'll be if vbox isn't consistently assigning display IDs...

– Chris – 2015-04-09T03:33:15.653

@Chris Well, it is a long question :) I haven't tried it--that would certainly be worth a shot. One strategy would be to set the "preferred" modes in gdm init, then use --auto in the i3 init (which seems to work pretty reliably when the preferred modes happen to be correct). Any idea if it's possible to manually set the "preferred" modes? – Kyle Strand – 2015-04-09T17:05:36.993

1Unfortunately, none that I can think of immediately, since VBox doesn't seem to consistently assign names to the monitors. Could you post the output of xrandr --query (a) when it's detecting the settings incorrectly, and (b) after you've gotten everything working properly? Or at least one from everything working correctly. – Chris – 2015-04-10T15:21:51.397

@Chris The names aren't a big deal, actually--I can just switch them if necessary, and in general they don't seem to change that much. The problem is that VBox apparently always reports the same set of "valid" modes for each monitor, but it's inconsistent about whether or not it reports the real hardware native resolutions. Actually....come to think of it, maybe it reports the valid set of hardware resolutions correctly, but xrandr is reading the resolutions at inopportune moments when one or more screens are disconnected. Where does xrandr actually get its "valid modes" list? – Kyle Strand – 2015-04-10T17:10:34.547

.....Also, I just noticed that in my current (valid) setup, the native resolutions are not replicated between the modes listed for each screen: i.e., each screen has some set of common low-res modes (up to 1024x768) plus one high-res mode corresponding to the actual correct native res. – Kyle Strand – 2015-04-10T17:12:23.627

I'm not sure how it got into that state, but I'll bet I could figure out how to coerce it if I understood better where xrandr is actually getting its info from. – Kyle Strand – 2015-04-10T17:13:01.550

xrandr should get the settings reported directly by the graphics driver via the RandR extension. I have a theory: The VBox driver, for compatibility reasons, reports every possible mode by default. There must be a hook in the driver that Gnome latches onto in order to function with the 'auto-resize' feature. If so, it may never work correctly with i3. I think the key is to figure out exactly where that 'auto-resize' function hooks into the display management subsystem... But I must admit that it's an educated guess at this point. – Chris – 2015-04-11T01:24:05.203

Could you provide laptop exact reference to see what underlying graphics hw you have. It is also important to understand what is the host OS. Have you tried updating to latest virtualbox ? – yilmi – 2016-01-15T17:55:02.477

@yilmi I provided the exact graphics driver version and also mentioned that the host is Windows 7. Is there specific additional information that might help? – Kyle Strand – 2016-01-15T18:21:04.033

The laptop exact reference, some laptop have dual gpu with wired output, if so pci passthrough might be a workaround. I went through changelog and saw that VirtualBox 5.0.2 could fix the issue a 3D issue that could match yours but nothing better than a try ;-) – yilmi – 2016-01-16T02:18:00.553

@yilmi Augh, meant to respond earlier. I'm using a ThinkPad W540, I think (it's not in front of me at the moment), or T540. Definitely haven't upgraded to VirtualBox 5 yet, so I'll try that. – Kyle Strand – 2016-01-27T06:54:24.393

@Kyle : The W540 and t540p uses nvidia as discrete video card which means that the Intel gpu is the main, nvidia gpu is used for offload. What drivers are you using on host OS ? – yilmi – 2016-02-05T13:28:21.453

@yilmi As I mentioned, there's a BIOS setting I'm using to make the Nvidia gpu the primary one. I'll check later. – Kyle Strand – 2016-02-05T14:54:49.320

@yilmi Actually I'm not sure what host OS drivers you're asking about; as I mentioned in the question, my graphics driver is nVidia version 340.84. – Kyle Strand – 2016-02-19T17:03:24.183

@yilmi Updating to the latest VirtualBox may have fixed the issue as described here. I haven't rebooted my machine in a while, but it does seem that I'm consistently able to maintain the correct screen settings despite hardware monitors being disconnected, going back and forth between windowed and full-screen mode, etc. One new issue is that when I disconnect and reconnect physical screens then try to view the guest OS screens, I can only see the pop-up VirtualBox toolbar until un-select and re-select View->Full-screen mode. – Kyle Strand – 2016-02-25T20:23:41.043