Windows Tools failing on Multi-Monitor?

[Jose]

The card is Nvidia 600 Series.

First installation, I was being careful and only plugged one monitor. The windows tools installation went well without any problem. The VM was started and the display inside Windows 7 said (Default Monitor) on Qubes Video Driver. Seamless GUI is disabled.

I shut down the VM and plugged the other two monitors (triple monitor set-up). The VM won't start. Sometimes it would go green and sometimes it would hang on yellow indefinitely but no GUI or anything. qrexec_timeout was set at 300

Next, I removed the other two monitors and the VM started again flawlessly (Seamless GUI still disabled and I get a resizable win7 desktop window in qubes). Then I plugged in the other two monitors and everything is still fine. 

Anything I'm missing? Please not that I'm a new Qubes user. Thanks.

[Jose]

p.s. some clarification. I plugged in the other two monitors while the VM was still running and nothing bad happened.  The VM still won't start if all three monitors were plugged in at the outset.

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jose:

Is this a reliably reproducible issue for you (i.e., across
host reboots)?

Are there any problems when seamless mode is enabled?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXBNSjAAoJEJh4Btx1RPV8MfkQAKie7ci+BErVdm9bPwqaYWOa
krqAcW5dAJO3aArp4r0enIM5w/dIIq55cqPTH+UFl1ohMT2haO+MaE92mzLluzH8
G1mROlcxZ2RDOs0VxBJQKBtdyhLiOjzciQEDTXs//7BZU2tG/MR/dX3IXEJczPoM
v3chHxQgluWo8M922nLov70KEHPoDsaFKhMsZuwSYUfgf3F/mp8fDYHQSM3VOiO+
JSiaks0MXu7KkW8TvY5bE7d12O8Rr2bc8c4gvIwXBeiinUxuoF7snMTr/It2W8Ci
ifosSARG82i/wIPPcxfxU0B+T4gR/s3G0n++241ExjfJ88sT+tHMThMBdM2o0iT8
G2TftbnMlUZO+fUs2Z3XdA9eNpINgkGN8VJ1oNZB4FT6trGH9C5idAeCap31xk1n
o6/9oBmBCSIz05nGOGUWx7KLh06jDci5E5FazsenjqXAcouyt0HdAwHktAa4jhJG
4DRCrwqWekJ9Uo8M4Y9b+6dBQLIrqPEGGXN3r2Yghvw//V8pVefdF9nhJyOFjMXB
MMkDQ+avCUc8/VHgDXiWN4TiEswO4XTR6MJ7a0QjPXAS92Y8hij/v+Qb7SY9N6rn
BbOF0eXtTEm3AfZFiZsh/IyZw4x3xW6nFB6Tv7s9KaBwgyCfiDCTn+wUAaUFHEea
f1b0jRaHl6ETET3jEy2W
=hTMl
-----END PGP SIGNATURE-----

[Reg Tiangha]

I'm in the same boat and it's reproducible. The VM will start if one monitor is active, but it won't if you enable more than one. The workaround is to disconnect the other monitor before starting up the VM, either physically, or by going into dom0 System Settings and temporarily disabling all the other monitors. Once the Windows VM has loaded up, you can re-activate the other monitors. You can even move the Windows VM app window to the other monitors, however, you won't be able to click on anything in that window until you move it back to the original active monitor.

I have a theory about that based on what I've observed. It looks like seamless mode depends on having the entire desktop resolution available to render stuff on; there's another thread somewhere around here where people have found issues when the Windows OS desktop resolution doesn't match the dom0 resolution. If you look at Windows display properties when you activate the other monitors, Windows still only sees the single monitor resolution. So my theory is that when you move that window to another screen, it's just like in regular Windows when you move the window off screen. You can do it, but once it's outside of your screen, you can no longer interact with it.

So my theory is that whenever you extend your desktop across dom0, that new resolution isn't passed to the Windows VM which is why you can't do anything with the application window once you move it to a second monitor. And the VM probably doesn't start up correctly when there's more than one monitor active because Windows Tools 3 gets all confused. It works fine in Safe Mode, however.

I don't know how you fix this, but maybe it's a hint on where in the chain to look at for potential issues/fixes.

[Reg Tiangha]

Edit:  Also, I too have an Nvidia video card. I don't know if this is an issue with other brands like Intel or AMD, although I'll be setting up a second test system this weekend that has an AMD card, so I'll probably test this again on that one once it's set up.

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Reg Tiangha:

Thanks! The issue is being tracked here:

https://github.com/QubesOS/qubes-issues/issues/1704


(P.S. - Please avoid top posting.)

iQIcBAEBCgAGBQJXBgGEAAoJEJh4Btx1RPV8fdwQAJbiAXYRnA7liWsAYK3Fi3X0
YE2Osm8QgSzjdu4z9PVQWU8m5d3sbYY1+eRqlBN9/m7eA6DoZWvQDYirzxgeMGNR
DrNwjxIugQCc0Wa5ksmFohllpY0Sppd/x9XI8PjoiKsKBtbGGup0dYOE5fDrzCRR
TGLzUl6ICTQHOYtoZIkWX7x0mPfWiDtd9kVW7s/wXBXNUSn6mNtcYb5HyYNOk1Nr
LN8+Jnb1UBsh7RBSCyqgFgEO6TFoFR6sg71tXBPjKfIM2Ka7tsZRSRa1XvE0uIkC
PGVFcxbD6FjTAuE0/FQ3kNnFP4DpK87UDW3x/Fmw5ZvvUoKLqwug3RhqM77GR9s9
7IND94sqUprtHmoyh09sBdDO4WzLtDZk1JuXxt2Ovg/A2OhxpNCh0pKKisQ/OOmj
GjtxEi6b1L/Xh92Gh0oHyQdUaINIYenWBZRtHJfrWzL4r2GKM+7nQKSabdqdakPT
iYRYjAL6m88lawPOV+Nz9W4q6yNll8dgFq4Xs0bQXWNW0i9xKn5ebXqq+XsaJR71
nhuSPf5Bz0C7HdmASMpKDaBahh0ZOz8FXungCFFYiaiyzK/6DcOFz2wcYjleQcdF
UukIVmSc1fcVZvFrvVcqS3GsPAoxk83pJ2eEMBUCLBbnCTWa7K7EUGRuLXFrtOZ2
5WDV7tXBKceQGC68aHEa
=hrBq
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Apr 06, 2016 at 11:23:46PM -0700, Reg Tiangha wrote:
> I'm in the same boat and it's reproducible. The VM will start if one
> monitor is active, but it won't if you enable more than one. The workaround
> is to disconnect the other monitor before starting up the VM, either
> physically, or by going into dom0 System Settings and temporarily disabling
> all the other monitors.

This problem is related to total screen resolution. Apparently Qubes
Windows Tools doesn't work with large screen resolutions:
https://github.com/QubesOS/qubes-issues/issues/1896
https://groups.google.com/d/msgid/qubes-users/20160329002536.GE14681%40mail-itl

> Once the Windows VM has loaded up, you can
> re-activate the other monitors. You can even move the Windows VM app window
> to the other monitors, however, you won't be able to click on anything in
> that window until you move it back to the original active monitor.
>
> I have a theory about that based on what I've observed. It looks like
> seamless mode depends on having the entire desktop resolution available to
> render stuff on; there's another thread somewhere around here where people
> have found issues when the Windows OS desktop resolution doesn't match the
> dom0 resolution. If you look at Windows display properties when you
> activate the other monitors, Windows still only sees the single monitor
> resolution. So my theory is that when you move that window to another
> screen, it's just like in regular Windows when you move the window off
> screen. You can do it, but once it's outside of your screen, you can no
> longer interact with it.
>
> So my theory is that whenever you extend your desktop across dom0, that new
> resolution isn't passed to the Windows VM which is why you can't do
> anything with the application window once you move it to a second monitor.
> And the VM probably doesn't start up correctly when there's more than one
> monitor active because Windows Tools 3 gets all confused. It works fine in
> Safe Mode, however.

Your theory is right. When screen resolution is changed, Qubes agent
inside Windows VM doesn't update screen resolution. This part simply
isn't implemented yet. This is the first step for supporting
multiple monitors - the second one is setting appropriate monitor layout
there (instead of one big monitor across all of them).
https://github.com/QubesOS/qubes-issues/issues/1704

Have you tried disabling seamless mode? Does it work then (when you
extend VM window across all the monitors)?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXBiIKAAoJENuP0xzK19cspvcH/iaS8Trq9rGyU5Oh1NtPGxK2
ymsVB6+fOXKu+VSKCH1n8JwrkgxOZRtG3cEXDoSAYMrqoXBJEk9ws6ynWk+KjPPu
bTOOkM+lId3bYMJwldwqGDsROWMfUA9Wb1urzqlJU+gt8jXe4acvxyAUOfYhGkHU
58oIX2EKr3iP6Y73lsWWhfINZ1Lo+Dhi0zXPOTqJ11lFh0K/3fAFFwTguoMvqE2a
J+8Xqbg/UUVE3gxPAjnnf31JkwaqBDBBgT/kM67+c3Za5pgaAkJX5/YxJN2NLicM
8WP/hk9VKBKjGOaNRg8KHAWJa/FwORTpSMLir4lDU9zCmlyPQDWmsz5MB/COu0I=
=r9AH
-----END PGP SIGNATURE-----

[Jose]

Apologies for the slow reply.

It is reproducible in my machine the same as Reg Tiangha posted. 

My problem was that after Windows Tools installation during the next reboot I gather that the private image is moved. With the three monitors connected, this messes up the procedure and the VM permanently. What I had to do was disconnect the other two monitors and complete the installation of the Windows Tools with one monitor. Right now I'm running Win7 with seamless mode disabled (GUI agent also is disabled IIRC). 

I would like to make a note in addition to Reg Tiangha's observation.

Outside Qubes, my Nvidia card already had problems with Fedora 23 with regards to multiple monitors and I had to install the RPM fusion drivers. I attempted to install the RPM fusion drivers on dom0 but the command with "yumdownloader --resolve xorg-x11-drv-nvidia" resulted to an error. Currently everything is working fine and I'm a bit hesitant to mess it up.

Just a note that the problem of my card with Fedora 23 might be playing a role. 

[Reg Tiangha]

Yes, screen layout was my second concern. For testing things, I use a desktop with a front hard drive bay and swap hard drives, rather than multi boot off a single drive (since I have a lot of small capacity hard drives now). Qubes is the only OS that swaps my monitors. Sure, I could fix it by swapping my monitor cables, but out of the 4 OSs I use on this thing, I'm not going to do that. Luckily, it's fixable in dom0 System Settings by rearranging the screens, but if Windows doesn't inherit that, then there could be problems if large resolution support were one big monitor across all of them. Plus, it wouldn't handle the use case where there are mis-matched monitors attached to the same system; for example, laptop hooked up to a display with a different resolution or aspect ratio (say modern 16:9 laptop to a 4:3 monitor). So ideally, in my head, the best way for Windows Tools to work would be to pass along both the resolutions of any display devices attached to dom0 (whether that be 2, 3, 4+ monitors) as well as layout order and then implement them in Windows as separate displays rather than one big one.

As for disabling seamless mode, even with that turned off and debug mode turned off and on (I tried every combination in the truth table), the VM still won't boot; the only way it'll boot successfully is to disable all the other display devices first. I haven't tried disabling it once the VM has booted with only one monitor attached to see if you can interact with the application windows after dragging it to another monitor, though; I'll add it to my test cases on the weekend when I have more time again to play around.

[Reg Tiangha]

Oh, and as for QWT not being able to handle large resolutions, is that an issue of not enough video ram being allocated to the Windows VM?  In Virtualbox, it actually throws a warning at you saying that if you want multi-monitor support, you need to allocate at least 128MB of video RAM to the VM, and ideally 256MB. I can't see a setting for that here in Qubes, so maybe what's being allocated currently is hard-coded at a small amount and that's why it can't handle larger resolutions past a certain value?

And as for Jose's issue with RPM Fusion not working; it's weird. I've found that the RPM Fusion repository rpms are installed in the template VMs, but you can't seem to access the repositories. If you uninstall the RPM Fusion rpms and then re-install them, then the repositories become active and you can access all of their packages. I'm still new to Qubes, so I don't know if that's expected behaviour or not.

That said, I wouldn't try installing the Nvidia drivers just yet. They don't seem to work (everything I've read say that recent versions don't work with Xen kernels) and when I tried it, I just got a blank screen. I made the mistake of making xorg.conf modifications as well, and ended up having to reinstall everything because I couldn't figure out how to mount the drive in single user mode and then log in to make changes (it asks for a root password and I never set one) in order to revert things, so I had to reinstall Qubes (and no, I didn't make a backup first, lol). That said, I don't necessarily mind if that's expected behaviour; it means that someone else can't access my drive in single user mode. If you need a slightly newer Nouveau driver, install the 4.2.8 kernel from the qubes-unstable repository. On my Nvidia Fermi card (GTX 580), I get a bit more stable performance using the newer driver bundled with that one, rather than the stock 4.1 kernel.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> > Yes, screen layout was my second concern. For testing things, I use a
> > desktop with a front hard drive bay and swap hard drives, rather than multi
> > boot off a single drive (since I have a lot of small capacity hard drives
> > now). Qubes is the only OS that swaps my monitors. Sure, I could fix it by
> > swapping my monitor cables, but out of the 4 OSs I use on this thing, I'm
> > not going to do that. Luckily, it's fixable in dom0 System Settings by
> > rearranging the screens, but if Windows doesn't inherit that, then there
> > could be problems if large resolution support were one big monitor across
> > all of them. Plus, it wouldn't handle the use case where there are
> > mis-matched monitors attached to the same system; for example, laptop
> > hooked up to a display with a different resolution or aspect ratio (say
> > modern 16:9 laptop to a 4:3 monitor). So ideally, in my head, the best way
> > for Windows Tools to work would be to pass along both the resolutions of
> > any display devices attached to dom0 (whether that be 2, 3, 4+ monitors) as
> > well as layout order and then implement them in Windows as separate
> > displays rather than one big one.

Yes, that's the goal. Such information is already available to the
VM, but currently it is implemented only for Linux VMs. Rafał (our
Windows guy) is currently working on totally new video driver, using new
video driver API (WDDM). This will make the QWT compatible with newer
Windows versions, but also make it easier to support multiple monitors
and hopefully improve performance.

However it will take some time, because WDDM API is quite complex and
documentation isn't very helpful. So, if anyone know WDDM API, Rafał
could use some help.

> > As for disabling seamless mode, even with that turned off and debug mode
> > turned off and on (I tried every combination in the truth table), the VM
> > still won't boot; the only way it'll boot successfully is to disable all
> > the other display devices first. I haven't tried disabling it once the VM
> > has booted with only one monitor attached to see if you can interact with
> > the application windows after dragging it to another monitor, though; I'll
> > add it to my test cases on the weekend when I have more time again to play
> > around.
> >
>
> Oh, and as for QWT not being able to handle large resolutions, is that an
> issue of not enough video ram being allocated to the Windows VM? In
> Virtualbox, it actually throws a warning at you saying that if you want
> multi-monitor support, you need to allocate at least 128MB of video RAM to
> the VM, and ideally 256MB. I can't see a setting for that here in Qubes, so
> maybe what's being allocated currently is hard-coded at a small amount and
> that's why it can't handle larger resolutions past a certain value?

When QWT are installed, it shouldn't matter anymore, because it contains
virtual video driver, which doesn't use any emulated hardware. It
allocates memory out of system RAM (by default 512MB, but most likely
you've increased that for Windows installation).

Anyway there is some bug preventing QWT from working with higher
resolutions. We haven't found out where, yet.

> And as for Jose's issue with RPM Fusion not working; it's weird. I've found
> that the RPM Fusion repository rpms are installed in the template VMs, but
> you can't seem to access the repositories.

Those repositories are disabled by default.
Take a look here:
https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-9

Anyway that's only about VM, dom0 have no such packages installed.
And installing Nvidia drivers is at least tricky, as you've already
noticed. Mostly because not being compatible with Xen, but also because
of specific of Qubes environment (network-less dom0 etc).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXBnNWAAoJENuP0xzK19csIq8H+QGCuVkjrIll5N+aT+qw0sij
l8RXmDm2hCwQlC6ZkmmDXJLXDmfu5OH5cLNAxXV7dafRjXXuNY6QC01bOrG7OPUP
SdSBVRmK0YvZAWhvbt1hD3mTulUn4+vGayGzaufCGcVCGiCYJZnLgfeFykjcEkDS
dlifaRXMh27sngL7g0PXFEoN+0FXCrA1zktxMUI4M7ObUFDJq20JAIFlSuYnblul
Frsru9itwwAkBe9ahAuEQg0ZYwfrWouB5+Hub+zPS1deoECchUP1MoVdcVLvo1iL
nDuDM18K5uo5XjeLrn30GtTDrzO50+gowoCdVuLzFP4IHogkByL05gb7jRPcr+c=
=Xqay
-----END PGP SIGNATURE-----

[Reg Tiangha]

But does it really set the VM's VRAM correctly? In my /var/lib/qubes/appvms/Win7/Win7.conf file, I found this entry in the <devices> section:

<video type='vga'>

     <model type='xen' vram='16384' />

Now if that's the case and it's only setting 16MB of VRAM, then that could explain some things, because in order for my dual 1920x1200 monitors to be supported at 32-bits, I'd need at least 17.58MB of VRAM in order for things to work properly. I tried manually editing the file to bump up the VRAM total to 65556, but the conf file got overwritten on boot up. So I don't know where it's pulling that default 16MB value from, but perhaps bumping that value up might help with the higher resolution issues?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

As I've said, this value is not used after installing QWT, because QWT
don't use emulated VGA.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXBofvAAoJENuP0xzK19csXO0H/jMFlrI97M0zNfRCZNjHrcgu
+sNVaTusnPkKH6Z78qDd41XwbRYoUV4tvLCgDgr8IZKvkcRWyVkoccRvEKk/bi23
LwrcJLmVYAMNaUXSzOAXgHVSCG1s+k9ozg3fP/lzgN/g53wjwRyi3Q4V3Jke0DSL
JGF2MXh7R4B7R+BOVPmJg810AjK5SOUGfUvaJNLSucPZEfVui5vmJZjOgEI83fe6
6x74s9F0Flb59cbT6jhFknlxjfbeHoC8OewLV4ToMgoCtvkwW1WEQCwz6TNCOCBU
9afMhoVAk4ucgK1xFG1i+4/+v/Y7VTS/0JkfMgt+cXtQVjABAbqfwB2CN1OEVXE=
=/Aa4
-----END PGP SIGNATURE-----

[Jose]

Thanks for the warning about installing the Nvidia drivers. I was hesitant to continue further when the repository error came up because everything is working already (at least I've learned how to enable them if I decide to go through with it). If I managed to get more free time I'll experiment further. It would be nice to get the seamless gui enabled.

Correct me if I'm wrong but I think the difference in our case is my Win7 VM is booting even with all three monitors attached (after completing the tools installation with only one monitor). Some details: guiagent_installed False, seamless_gui_mode False. No problems moving the VM window all around. I believe the seamless gui was working with one monitor because I got separate pop up windows for reboot and successful install enclosed in the VM's label color. When I have the time I'll verify this and test it further.

[Jose]

Just some details. Hopefully it will be of help.

Current working condition: Installed Windows Tools without the Qubes GUI Agent with only one monitor enabled during installation.

Results: Three monitors plugged in after installation. Windows 7 desktop window working on three monitors. No problems whatsoever.

TEST 

One Monitor

Cloned the working win7 template for testing and installed GUIAgent.

name                : win7-x64-TEST

label                 : black

type                  : TemplateHVM

netvm                : sys-firewall

dispvm_netvm    : sys-firewall (default)

updateable        : True

autostart           : False

installed_by_rpm      : False

include_in_backups  : True

last_backup         : None

dir                       : /var/lib/qubes/vm-templates/win7-x64-TEST

config                  : /var/lib/qubes/vm-templates/win7-x64-TEST/win7-x64-TEST.conf

pcidevs              : []

pci_strictreset     : True

root_img            : /var/lib/qubes/vm-templates/win7-x64-TEST/root.img

root_cow_img       : /var/lib/qubes/vm-templates/win7-x64-TEST/root-cow.img

root_volatile_img  : /var/lib/qubes/vm-templates/win7-x64-TEST/volatile.img

private_img           : /var/lib/qubes/vm-templates/win7-x64-TEST/private.img

vcpus                : 8

memory             : 4000

maxmem             : 4000

MAC                : ########################

debug              : off

default_user         : ########################

qrexec_installed    : True

qrexec_timeout       : 300

guiagent_installed    : False

seamless_gui_mode  : False

drive              : None

timezone           : localtime

internal           : False

After GUIAgent installation

guiagent_installed : True

seamless_gui_mode  : False (supposedly?)

First run: No problems. Opened Windows Media Player and it opened in a seamless gui mode (independent window, not inside a contained Win 7 desktop. I was surprised this worked since seamless gui was supposedly disabled.)

Second run: Long start up. Graphics corruption. Win 7 hanged on load with the circle pointer. CPU usage skyrocketed to 95%

Killed the app.

Third run: No more graphics or windows opening. Just the VM loading and the CPU usage skyrocketing to 99%

No longer bothered to test for triple monitor.

NVIDIA GeForce 600 series

Final Thoughts:

Currently I'm satisfied because I only wanted the Windows Tools to move the user profile to the VM's private disk. I want to run Win 7 from a template and preserve the user's data. I'm hesitant to conduct further testing with the CPU usage going 99% all the time.  

p.s. New to Qubes and hopefully I got some terminologies correct.

p.p.s. New to group discussion in google also. Hopefully I got the bottom posting right.