Qubes achielles heel: video drivers?

[cubem...@gmail.com]

I've been testing Qubes on a variety of machines and it works well; except the one consistent problem is the graphics drivers. Both AMD and Nvidia have issues - yes I know there are workarounds, and I know some configurations work out of the box, but it seems clear that this is likely a central issue.

The wonderful Qubes team has gotten funding to enable EFI boot which is an interesting feature to pay for; I wonder why the money was put on that? Consider that Qubes is really meant to be run on high end machines; you want VT-x/etc, TPM/TXT ideally, and you need lots of RAM and cores to adequately perform when running so many hypervisors securely. So, a high end or higher end machine typically means one with with a discrete GPU too, yet I've seen only the Intel GPU work reliably (there are a variety of different issues on both platforms, such as sleep, video blanking, external monitors, etc).

I can see a couple mitigation's for this, easiest to harder ...

1. Offer an install option to disable all AMD (radeon)/Nvidia (noveau) GPU drivers. I've not seen either work reliably, and have not yet had success in disabling them (kernel command line options, bumblebee, etc). Ideally I'd like not to install them in the first place, or at least we can have a FAQ describing how to do it (if somebody will explain to me I'll write it)
2. Have a way or document how to install proprietary drivers. I'd install AMD drivers which I have, but haven't yet figured out how to do that (or if I even can)
3. Focus on fixing the bugs. I'll volunteer my time on this if the team decides to go this route.
   

Anyhow I think the EFI work will just exacerbate the issue (now it will run on Apple laptops with discrete graphics?), and am willing to help however I can (including code work)

[J. Eppler]

Hello,

there is a guide on how to install Nvidia drivers:
https://www.qubes-os.org/doc/install-nvidia-driver/

by the way you should consider posting this message
in qubes-devel instead of qubes-users.

Best regards
  J. Eppler

[Dave Ewart]

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

On Monday, 07.12.2015 at 08:39 -0800, J. Eppler wrote:

> Hello,
>
> there is a guide on how to install Nvidia drivers:
> https://www.qubes-os.org/doc/install-nvidia-driver/

Is that documentation up-to-date? It refers to Fedora 18 and kernels in
the 2.6.x series!

Dave.

- --
Dave Ewart da...@sungate.co.uk, http://twitter.com/DaveEwart
All email from me is digitally signed, http://www.sungate.co.uk/
GPG key updated Jan 2013 see http://www.sungate.co.uk/gpg
Fingerprint: CF3A 93EF 01E6 16C5 AE7A 1D27 45E1 E473 378B B197
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQQcBAEBCgAGBQJWZbn0AAoJEEXh5HM3i7GX6jwf/0kuxm7623no9Y5SGLlD29M4
/NTN7qgmb2yHilelPkdg+hfopqJs/+FUTI9GkzGxVHvrFpzleRXCRvsbUxK3IGf8
M3mPB8alSejgXWIOpegPJGZALl5WVUQau0hV6Np/i7SNob1vLV6k6syJ+A7sRepy
ATyBpQ8qC3FoZTLmiAWI58b2jZCBW24lkFP/9GM/4hKmdJ8Q8VWavV4Nj4RdfU63
NmXc5bHpK710npiLjTYHpCjIm0Y9xUOb3Tx7eByBX7jNK4K7XnmHWUcLu8/xHX05
7DNbUcjjeRXRsvkBdgr1i444ahJCRbWIOrQq7jASOlyga+71pudPUbVjBLSAo9oh
lGSpMH87w7ZC0iMBvX9hUlHSKg9lIyrTTNOSxIFW3FBfIdkNL8mgYeWeUsGIehSY
K3vg8pWmMMySguMiL482h44Rvdcj4cJW6+pl9X0Q/rmQnbZrhl/ZXfi/7OM20Ehb
Ag/erqeRy0T68gSx2tWkWb5KTnxkAKDGs1pLsP1a1Q+FTfR2NImGJwFI6bT7yxGF
kx1cka8KpGF6VwQJoIEE6cFvz1EYkCPhlKhmNuDAyKZUmiZX0EryZM0iFyNSt7Mt
cxpSk+b7jslbNtNT0mimhFR/xSJCCF67juR/O+xWn36pU+eBMiq7XZKJtuW+ofUW
RbTgoPSexmJobujSdi20JWaXuue2p47jSFNhedOsyi2RvGAAJKj4/viOdd50j/5Y
GPU2ICTHumKWysVTumbnDZAFgYj+4gvAhqqgVemTA7m9cwUIWeVJLD2JgxrHrHFn
RCyYMLRJEJppR844Su7x1ijcrVrCM1/NoQYNTlRiuGwaJGM+9SeU0UHqzlbEXzgG
Whv5vcyCUyxkrjZFQLnlcA33CH9c52WHIYUhoAmsc28pp+Om5R3QLqzBX71z+jVC
mSeQnuY4rG+KxVQ7JeDyAFW8aD11/9W8bavRKxmpg9TtOCdwmMccaqd23gIRFB6g
f+9asrSZ/tOjIBJpw7SV9zLJhEFavKxVeT01iP4au5yBdbgjP5dOonyT69+a+ka/
3npj29ZeNQiGowuykcjCc5pDcvV25GRNrXRwgHt+JD9IKFS788JpZgxrc36WEB/0
SvdhWX7wtqXf182xtT0iTPmQkSXwtskueGb7l93RgWBnbqhVhdqjvRoNQdXkUZbK
bLIiEFcDDW0AkFSdVeOXTbrhzSwohUksAzPczOmTEMVAtu6wbzSUxOMm//m2ytZI
ycUDmA5VGnns7iwFDxrFPGhJx4YV5aHpWliYujzMpGOTKztOTmBgXIdKOXl9CkMl
erdA1arfLzHyCNhyZx1dDy4t/1Q5yY3ab1DnBlrmu7fXyGTa3Vu5+Zsv9WnDA9c=
=7j94
-----END PGP SIGNATURE-----

[J. Eppler]

Is that documentation up-to-date?  It refers to Fedora 18 and kernels in
the 2.6.x series!

Yes, sorry the guide is outdated, but you can find more
entries about installing Nvidia in Dom0 wit a google group
search.

You can find an installation guide here:
https://groups.google.com/d/msg/qubes-users/k3gtee7rCUY/QgiKcQCrAgAJ

Best regards
  J. Eppler

[cubem...@gmail.com]

Thanks for the commentary but it mostly misses my point :)

I wasn't looking for specific advice, good points but I'm already well aware of them (and specifically am working on AMD issues not Nvidia, which has less documentation anyhow), rather I'm commenting on what I see as what seems to be a major stumbling block for installing cubes. I am looking for user feedback before I take it to the developers.

[thomasf...@gmail.com]

I believe Microsoft have removed the requirement that "Windows Certified" computers must have a legacy mode EFI. As a consequence, there is a genuine possibility that future computers simply won't ship with a legacy mode and Qubes in it's current form simply won't run.

One of the Qubes devs could provide a definitive answer, but I suspect this is the reason for prioritising EFI.

[Marek Marczykowski-Górecki]

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

On Tue, Dec 08, 2015 at 02:44:56PM -0800, thomasf...@gmail.com wrote:
> I believe Microsoft have removed the requirement that "Windows Certified" computers must have a legacy mode EFI. As a consequence, there is a genuine possibility that future computers simply won't ship with a legacy mode and Qubes in it's current form simply won't run.
>
> One of the Qubes devs could provide a definitive answer, but I suspect this is the reason for prioritising EFI.

Yes, exactly. There were already reports of laptops without legacy mode
support and probably there will be more of them in the near future. We
need to keep Qubes installable on the most recent hardware.

- --
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

iQEcBAEBCAAGBQJWZ17EAAoJENuP0xzK19csOXUH/2D7i4E1FKaT6lD853hXW+Dq
5zOND/G1jmE7F/2Ll1wn9g8mLh4vvhjEr7y0tlB86Ip2HyWVSVJNxI8yViXkE0Sr
+HaiA7parZ7QPISRjjoFk42S21GxqNP9kHfkYg68t4rrYwTA5xapXPdhnx2CTzR4
8YM8/TClUTTgdxtnYOZR5t/Qc+oWCunkilR7kySNE9RxYQfFW3diLg4QkK96KG/G
4Ht/LoFxl8MJqtlyiFcGkzo0secWuoHWP6TxEPCHxEPzDW4NNecpmww6pg1G0WbK
Ugjc4zAEoSBzzQDP9FAKnwHrYOgMcB8o+SP5KEHJY7k+2h0ALi6qtXg8DICfYwY=
=8JAx
-----END PGP SIGNATURE-----

[Tim W]

Along those lines also make sure whatever model does not have the secure boot disable feature removed..  Apparently MS has been pressuring manf to lock the secure boot enabled with only there key in the ring.  This seems to be mainly seen on lower models where profit line is very thin and a few dollars matters .  Regardless it would suck to think you were OK because you had a qubes UEFI and then find out you at best needed a key to have it load or worst could not even add it even if you had it. 

Marek and others,

Is there any benefit or downside to using either UEFI native mode vs CSM/BIOS for Qubes i.e. one over the other?

[Vít Šesták]

I see no point of using a dedicated GPU in Qubes if there is an internal one. (Except for additional video output that is not controlled by the internal GPU.)

I've successfully installed Bumblebee on Qubes 3.0 several months ago and it still works fine. I don't have Nvidia proprietary drivers and Nouveau don't seem to be used. There are my steps summarized: https://groups.google.com/d/msg/qubes-users/s2oOT1nTFkw/GflmP2FmFAAJ

It would be nice if someone confirms that this works on clean Qubes installation. I might theoretically have done some steps (e.g. installing TLP and bbswitch) that seem unrelated to successful installation, but this theoretically might not be the case. Or maybe I have something important forgotten. If you look at the original thread where I described my steps in a monologue, you will see I have done some experiments while facing two (already fixed) bugs. But maybe I can help you when trying it. I am not aware of anybody who has either confirmed or denied that the mentioned steps actually work for other machine than the my one.

Note that I am not sure if just uninstalling all the Nvidia drivers is a solution. Not having any drivers AFAIK implies not saving the power in any way. (But I might be wrong.)

Regards,
Vít Šesták 'v6ak'

[cubem...@gmail.com]

On Wednesday, December 9, 2015 at 12:04:34 PM UTC-8, Vít Šesták wrote:

I see no point of using a dedicated GPU in Qubes if there is an internal one. (Except for additional video output that is not controlled by the internal GPU.)

Performance, ability to run multiple external monitors, ports not available to internal GPU as you say.
 

I've successfully installed Bumblebee on Qubes 3.0 several months ago and it still works fine. I don't have Nvidia proprietary drivers and Nouveau don't seem to be used. There are my steps summarized: https://groups.google.com/d/msg/qubes-users/s2oOT1nTFkw/GflmP2FmFAAJ

I have an AMD chip

Regardless the point is that from what I'm seeing the GPU is the most difficult issue with installing and using Qubes at the moment.

[raah...@gmail.com]

aren't gpu's a security risk though?

[Marek Marczykowski-Górecki]

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

On Tue, Dec 08, 2015 at 08:47:28PM -0800, Tim W wrote:
>
>
> On Tuesday, December 8, 2015 at 5:50:53 PM UTC-5, Marek
> Marczykowski-Górecki wrote:
> >
> > On Tue, Dec 08, 2015 at 02:44:56PM -0800, thomasf...@gmail.com
> > <javascript:> wrote:
> > > I believe Microsoft have removed the requirement that "Windows
> > Certified" computers must have a legacy mode EFI. As a consequence, there
> > is a genuine possibility that future computers simply won't ship with a
> > legacy mode and Qubes in it's current form simply won't run.
> > >
> > > One of the Qubes devs could provide a definitive answer, but I suspect
> > this is the reason for prioritising EFI.
> >
> > Yes, exactly. There were already reports of laptops without legacy mode
> > support and probably there will be more of them in the near future. We
> > need to keep Qubes installable on the most recent hardware.
>

> Along those lines also make sure whatever model does not have the secure
> boot disable feature removed.. Apparently MS has been pressuring manf to
> lock the secure boot enabled with only there key in the ring. This seems
> to be mainly seen on lower models where profit line is very thin and a few
> dollars matters . Regardless it would suck to think you were OK because
> you had a qubes UEFI and then find out you at best needed a key to have it
> load or worst could not even add it even if you had it.
>
> Marek and others,
>
> Is there any benefit or downside to using either UEFI native mode vs
> CSM/BIOS for Qubes i.e. one over the other?

There are some minor limitations in UEFI mode:
- installer doesn't have graphical splash screen [1]
- xen.efi is loaded directly from UEFI BIOS, without grub, so no way to
change boot parameters

The above problems will vanish when multiboot2 boot protocol will be
implemented in Xen and Grub[2]. But for now it's better to use "legacy
mode" if you can.

[1] See here for explanation:
https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-135988806
[2] Details at the end of http://wiki.xen.org/wiki/Xen_EFI

- --
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

iQEcBAEBCAAGBQJWaPTRAAoJENuP0xzK19csH6EIAIX3Os2Dhj8Ki595AA6/fVKL
MhBUQSOWVEbsIx/uyl+VpVbXrcH5KBR7NJ+LdtuwJ9CBcVV+fT6qtC1kp6sx/Rsv
Ve8HZgDwP2k8ia6WeoAd+FzuFZghsGupsn5ID/zwqlrAXrw6EM8A4353Iy22ZP9g
HfAutE7Cue0hqFZeLM7DH0GsNHVuKWDkreW3wFfJ+N14TxPZo+A4OeN6c+ZNJ+Be
x/zTq6ml76D9s/hLNS8M/+DQH3QXF39xIDnuPCHQLHFvu9pzUsQQCpYhT5uampCY
U0msGRch64sE2p4JFpMdqyF4lt+rYHtK0yewBdI9qmv2MX2jXkUcBfEjFl0cZeQ=
=PFM0
-----END PGP SIGNATURE-----

[Vít Šesták]

On Thursday, December 10, 2015 at 12:06:34 AM UTC+1, cubem...@gmail.com wrote:

Performance

I can't imagine any performance advantage over integrated GPUs when using with Qubes. That is, Qubes uses GPUs just in dom0, where you can get WM acceleration. But integrated GPUs are good enough there.

 

ability to run multiple external monitors, ports not available to internal GPU as you say.

True. However, this is AFAIK an issue on Linux in general, not specific to Qubes. At least with Nvidia.
 

I've successfully installed Bumblebee on Qubes 3.0 several months ago and it still works fine. I don't have Nvidia proprietary drivers and Nouveau don't seem to be used. There are my steps summarized: https://groups.google.com/d/msg/qubes-users/s2oOT1nTFkw/GflmP2FmFAAJ

I have an AMD chip

OK. When you have mentioned Bumblebee, I supposed you have Nvidia.
 

 

Regardless the point is that from what I'm seeing the GPU is the most difficult issue with installing and using Qubes at the moment.

I agree.

Regards,
Vít Šesták 'v6ak'

[Cube Mammal]

I can't imagine any performance advantage over integrated GPUs when using with Qubes. That is, Qubes uses GPUs just in dom0, where you can get WM acceleration. But integrated GPUs are good enough there.

I have a new very high end machine and oddly it's suffering from performance problems. I'm putting together notes on things I'm discovering; out of the box Qubes seems to be made for low end machines. First is memory, with 32GB Qubes actually suffers, so I need to limit memory in the VM's. Two is having 4/8 cores, so limiting vCPU's fixes that (by default they all get 8 cores and then suffer from contention). Final thing is that the graphics still seems to stutter too much, I'm still digging into it (might not be GPU related but inter-VM communication or something)

 

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/NnO9NFdpGbw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b1be5ecb-ced0-4af2-85b8-df24cc15c0bc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Eric Shelton]

Actually, there is a way to specify boot parameters (or at least it worked for me in the past) - via a xen.cfg (or xen-4.6.0.cfg) file in the same directory as xen.efi/xen-4.6.0.efi (/boot/efi/EFI/qubes).  You can specify any of the command line options for xen and linux that you can via grub on legacy boot.  In fact, for some reason there is an empty xen.cfg file being installed by R3.1-rc1.  Details of the format for xen.cfg are provided here: http://xenbits.xenproject.org/docs/unstable/misc/efi.html

Now I'm curious, since I am not using EFI boot on my current config - how does xen-4.6.0.efi determine which of the two installed vmlinux files to boot?

Eric

[Marek Marczykowski-Górecki]

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

Yes, that's true. I meant there is no option to specify them at boot
time. So if you need to enter some option to start the system at all,
you are out of luck. You need to use some other boot media for this.

> Now I'm curious, since I am not using EFI boot on my current config - how
> does xen-4.6.0.efi determine which of the two installed vmlinux files to
> boot?

If the system is installed in EFI mode, the xen.cfg is generated.

- --
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

iQEcBAEBCAAGBQJWab++AAoJENuP0xzK19csMXQH/0sgOOncbiwjshCDxC5+QS1P
4QNsvKncX48KH4V5+disajVrMhEa4oThW6oVgjxzY/atRel88978nWobrNUX/Itc
QIK4OofkzyPGF2VCKjr6KshGgLe/N0j06uWeXUb3SL071GWFKA4OKzE7FfXS3Nxo
od0fnnnW6QRRpHNQdM9ZLXapIlRQvcId0PtvLf1qfZBVYeene2LZSNNjbfzI/g3x
8M0NukjdmhWj4tpW9/p+UBuyfKaui8V2J2vuEGaAk9H0wtHWknftJLS7HC2ZL6vW
T2E3TmnygUodKNGjbsBX918vYVGip20hUXKaACULiR9elNc5AyHrHNaGo7y4tqM=
=Dsyx
-----END PGP SIGNATURE-----

[Cube]

Results of my investigation; stick with Intel GPU's. I'm unable to get
either Nvidia or Radeon to work reliably, after testing the same laptop
model with both GPU's. They have different issues, generally Radeon
works better, but eventually runs into a bug. Which is confusing,
because when running a regular Linux distro both work fine, so there
must be something with the Qubes drivers (like running an old driver
maybe - I'm not sure) that is the trouble.

'vgaswitcheroo' works fine, so I can stick with the built-in screen and
Intel GPU for now, but would like to run Radeon as that way I can use
multiple screens, maybe some day.

[Vít Šesták]

On Thursday, December 10, 2015 at 12:26:48 PM UTC+1, Cube Mammal wrote:

out of the box Qubes seems to be made for low end machines.

I don't think so. Qubes is rather memory-hungry, SSD is strongly recommended (I've tried running it fully on HDD, so I can confirm that having at least some parts of Qubes on HDD is a good idea…) and various features of CPU (most notably IOMMU (VT-d)) are needed for some features.
 

First is memory, with 32GB Qubes actually suffers, so I need to limit memory in the VM's.

Well, some issue related to this seems to be addressed by limiting dom0 RAM to 4GiB. Not sure if this is exactly the your issue.

BTW, I haven't seen such problems with 16 GiB RAM, which is far from being lowend.

Two is having 4/8 cores, so limiting vCPU's fixes that (by default they all get 8 cores and then suffer from contention).

I have a quad-core CPU with HyperThreading (=> 8 vCPUs) and I haven't noticed any issue that seems to be related to having too much vCPUs.
 

Final thing is that the graphics still seems to stutter too much, I'm still digging into it (might not be GPU related but inter-VM communication or something)

What workload type do you use? Where do you feel the stuttering?

* AppVMs don't have graphic acceleration, as it is hard (if even possible) to implement it in a way that meets Qubes security standard. This is OK for, say, fullscreen video (I don't feel any issue on 1600×900 screen) and Blender AFAIR runs also OK (at least for viewing), but it is not OK for some other things that require graphic acceleration (e.g. games).
* AdminVM (dom0) does have graphic acceleration, but it only renders minor things like window borders, window titlebars and so on.
* I've seen some artifacts (horizontal bars) when having low memory in an AppVM. While you probably have enough memory, you might either do something really memory-hungry or have limited the AppVM too strictly.

Regards,
Vít Šesták 'v6ak'

[Cube]

On 12/12/2015 06:57 AM, Vít Šesták wrote:

On Thursday, December 10, 2015 at 12:26:48 PM UTC+1, Cube Mammal wrote:

out of the box Qubes seems to be made for low end machines.

I don't think so. Qubes is rather memory-hungry, SSD is strongly recommended (I've tried running it fully on HDD, so I can confirm that having at least some parts of Qubes on HDD is a good idea…) and various features of CPU (most notably IOMMU (VT-d)) are needed for some features.
 

Oh I agree with you but felt that 3.0 didn't have the settings for a high end machine. Out of the box 3.1 does however, it comes with a 4GiB limit on DOM0, however the vCPU setting is still too high at the maximum of 8. I notice Qubes does better if you limit sys-* VPN's to a vCPU of 1, and give 2 to the AppVM's.

First is memory, with 32GB Qubes actually suffers, so I need to limit memory in the VM's.

Well, some issue related to this seems to be addressed by limiting dom0 RAM to 4GiB. Not sure if this is exactly the your issue.

BTW, I haven't seen such problems with 16 GiB RAM, which is far from being lowend.

Yeah I saw no problem on a 16GiB laptop, there's a bug with spawning VM's that only shows up > 16GiB

What workload type do you use? Where do you feel the stuttering?

When using multiple monitors the graphics slows down and stutters, eventually crashing, both on 3.0 and 3.1

I've given up on multiple monitors for now, maybe just trying one external monitor later. With the integrated graphics and the existing panel it runs beautifully, though like I say running the exact same machine with Ubuntu or something (AND three external monitors with discrete graphics) has no issues. Same issue on the same laptop with Nvidia graphics. Qubes just doesn't work well with discrete graphics, at least in my tests.

[Vít Šesták]

On Saturday, December 12, 2015 at 1:09:43 PM UTC+1, Cube wrote:

Oh I agree with you but felt that 3.0 didn't have the settings for a high end machine. Out of the box 3.1 does however, it comes with a 4GiB limit on DOM0

BTW, this can be easily added to 3.0, if you want. But I agree that the out-of-box experience with >16GiB RAM is somewhat suboptimal.
 

I notice Qubes does better if you limit sys-* VPN's to a vCPU of 1

Interesting. I didn't care about that, but maybe the overhead of multiple CPUs outweights benefits from it. Theory says that multithreaded I/O is pointless, because I/O is so slow that one core can handle all the I/O.

I would guess that the benefit of having less vCPUs should be rather negligible and unnoticeable. But if you have observed some speedup, how did you realize the speedup? Is it just subjective speedup? (If so, where do you notice it?) Or maybe you have performed some benchmarks?

and give 2 to the AppVM's.

Hmm, it might depend on what you do on the AppVMs. It might be worth trying on some narrow-purpose VM.

When using multiple monitors the graphics slows down and stutters, eventually crashing, both on 3.0 and 3.1

Aha, this seems like related to GPU drivers rather than to the inter-VM communication. External monitors may be handled either by the integrated GPU or by the dedicated one. For example, in my laptop, Intel GPU handles laptop screen and SVGA, while Nvidia GPU handles HDMI output. With more recent Intel CPUs (I have some old Sandy Bridge i7 from 2011…), there seems to be more graphical outputs, theoretically allowing more outputs to be handled by the Intel GPU, which would imply less need of dedicated GPUs and less related hassles. (It, however, depends also on the manufacturer, if the particular output is wired to integrated GPU or not.)

With the integrated graphics and the existing panel it runs beautifully, though like I say running the exact same machine with Ubuntu or something (AND three external monitors with discrete graphics) has no issues. Same issue on the same laptop with Nvidia graphics. Qubes just doesn't work well with discrete graphics, at least in my tests.

Hmm, I also had no luck with Ubuntu (tried 12.04 and 14.04) and HDMI output wired to Nvidia. Maybe newer distros have better support. Which, however, might be the cause of Qubes issues, as dom0 is currently based on old Fedora 20. Thus, there is probably a potential solution. However, upgrading dom0 to a newer Fedora is reportedly not so easy. It seems to be partially caused by changes in KDE5, but there must be IMHO some other reason(s) that I am not aware of.

Regards,
Vít Šesták 'v6ak'