Windows USB integration with R4.1

Audio is indeed much, much more clearer, but very choppy and lagging while System Interrupts and audiodg.exe take 15-25% CPU.

Is this enough for now?


Oh, sorry. I thought you wanted a feedback about your suggestion regarding disabling uas.

Oh that’s absolutely useful!

Sorry, just wanted to be sure you had a workable system. :slight_smile:

@jevank and the Qubes team will likely track the issue with streams (and therefore UAS) support within the USB->VMs feature set (e.g. kernels, stubdomains, usbip, etc.).


12 posts were split to a new topic: QWT on Win XP

I am having several problems with usb integration in qubes 4.1. I initially wrote in another post in a somewhat rambling manner, apologies can you delete, not having found this post immediately. I am trying to write the issue more clearly now.

I installed a fresh version of Windows LTSC as a Standalone VM after upgrading to qubes 4.1 from 4.0. In the previous version, the VM was working perfectly.

I followed the tutorial to install @jevank qubes-windows-tools-cross, which I also installed in dom0, and I had also already installed the package xen-hvm-stubdom-linux-full. I also installed the xenbus and xenvbd drivers as suggested in another guide.
My qvm-features output is

stubdom-qrexec 1
rpc-clipboard 1
os Windows
audio-model ich6

The audio works quite well and the VM starts up without any problems, suggesting that the gui features have been taken well. However, when I try to copy any files from another vm the output is:
Filed to execute qubes.Filecopy (From nameVM to namewindowsVM).

The content of the policy is $anyvm $anyvm ask. Modifications to it have not produced any results.
What could this be about? Should I perhaps modify the new 5.0 policy in some way? However, I still don’t quite understand how to do this. Should I install additional drivers? Could it be something to do with how I created the VM?
Any help is appreciated, thanks in advance.

Which tutorial and which version?

Which version too?

Which guide and why didn’t you use the ones provided with QWT?

Which policy, and what is the whole content of it?

Which modifications?

Sorry for my english, the tutorial is the readme file on github . It builded the versiom 4.1.67-1

Version 1.2.3-1fc32 enabling current-testing repo

At the beginning, I start from the official qubes-os page which link me to this github, that makes me install a previous version of QWT.
Only after a while and a deeper searching I finally found the QWT from tabitpro team.
I haven’t been able to read the forum for a while.

The qubes.Filecopy policy Which I mentioned above and which gives me the error. I tried some changes to allow the copy to the winVM without success, but always restoring the file.
The complete content is:

disp-mgmt-fedora-33 fedora-33 allow,user=root
disp-mgmt-debian-10 debian-10 allow,user=root
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect

## Please use a single # to start your custom comments

$anyvm  $anyvm  ask

Just a few days ago I’ve installed Windows 10 with QWT on Qubes 4.1 current-testing according to these guides:

The file copy works fine and I didn’t change any policies.
Also I didn’t build the QWT ISO by myself but got the ISO with latest version 4.1.67-1 from github as stated in the guide above.
Try to install the Windows HVM by following the guides above.

It is available latest qubes-windows-tools-4.1.68 in current-testing repository now.
[user@dom0 ~]$ qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools


I don’t have such a policy on my 4.1?
In 4.1 this is found in 90-default.policy and it is by default set as

# File copy/move
qubes.Filecopy * @anyvm @anyvm ask

And if you are running fedora-33, it is EOL and you should upgrade it to at least fedora-34, although I’m using fedora-35 since last year and find it great.
Maybe it’s a problem somewhere around this?

I had already set up fedora-34, thanks for pointing that out! I directly deleted the policy, which was probably left over from 4.0. After that I updated QWT to dom0 and did the windows update, but nothing still gave me the same qubes.Filecopy error.

So I decided not to be stubborn and to reinstall a WinVM, this time installing QWT cross IMMEDIATELY BEFORE doing any other action (Activation, debloating, installing programs, changing qvm-features etc). As also written in the Windows installation instructions in qubes.

Now everything works as it should. Also, no appmenus command needed. Thanks to the tabita-pro team for their work and you all who advised me.

I checked to install QWT over on a Windows 7 system. The installation got stuck on trying to reinstall the PV Network Class Drivers Package. Installing without the PV Network drivers went fine, and afterward, this package could be installed without problems, by changing the QWT installation. Funny.

I’ll check with Windows 10 and 11 in the next few days.

Upgrade with Windows 10 and 11 went without problems, and installation on a “virgin” Windows 7, too. So we finally have a version that can be easily installed on all three versions of Windows. Congratulations at @jevank!!!

I’ll update the documentation on QWT accordingly.

1 Like

I’ve updated the description of QWT installation and created a pull request. So, finally, Windows comes out of the shadow! (And Windows users need a lot of sun…)

1 Like

wonder how I get v68.1 …?
Whenever I do sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools it’s telling me at the end, that the newest version v67.1 is already installed…

With temporary enabled current-testing repo you need to specify action to upgrade existing package, default action is install.

qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade qubes-windows-tools
1 Like

I already considered if I should mention it - probably better to do it. I changed the documentation accordingly and created a new pull request.

Thanks for the hint!

1 Like

This looks like an appropriate place to ask this question.

I have a usb printer. I have drivers for windows 7 SP 1. The drivers are installed there.

I just created the sys-usb qube (that is modified for a usb keyboard and mouse) yesterday.

How do I get windows to see the doggone printer?

I’ve done the following:

  • update with current-testing repos
    sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

  • install advanced variant linux stubdomain (now available only in current-testing repos):
    sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing xen-hvm-stubdom-linux-full

  • enable feature to windows qube
    qvm-features [windows qube] stubdom-qrexec 1

(from the very first post in the thread)

The one thing I cannot figure out how to do in that list is:

  • update and restart sys-usb with current-testing repos too

because no command was given (it’s a debian-11-dvm qube.

I have no idea if I’m even proceeding correctly (I sure hope so, it took half an hour to download half a gigabyte of god-knows-what into dom0).

I’m pretty sure that after I get the software ducks in a row, the printer must be assigned to the qube in the Qubes device thingamajig, before the windows qube can see it.

You need to do this in the TemplateVM for debian-11-dvm (debian-11 or something).
debian-11-dvm is template for disposables but it’s still AppVM and not TemplateVM.