My experience so far with this wasn’t as satisfying as I hoped. When I only passthrough a single USB DAC device, the sound always gets lost after some time. But I need to do some more testing (passing through the whole USB controller, testing without looking glass) what the reason is. Under native Windows and the linux host the problem doesn’t exist.
When launching the client with -F how do you get back out of fullscreen?
never used fullscreen, just with Scroll Lock capturing mouse. Didn’t see any need for fullscreen yet (it kind of is anyway).
But can’t you still use ALT-Tab? This doesn’t get captured of the client for me
In Ubuntu 18.04, I just went to settings > Keyboard and enabled
ctrl+F to be a hot key for full screen. Works perfect.
When I first got Looking glass working I was running Linux Mint 18.3 KDE edition, with the nvidia proprietary drivers installed for my Host system. When I would play games everything was buttery smooth.
Now I am running Ubuntu 18.04 with the noveau drivers and the stock Ubuntu Gnome desktop and when I play games or use Looking glass period (even at the windows desktop) I am noticing stuttering.
Its almost like SLi micro stuttering, its doesn’t make thing unplayable, but it is mind blowingly annoying.
What can I do to make the stuttering stop?
you don’t need a “custom KVM script”. In the end virt-manager or respectively libvirtd does exact the same thing and starts qemu with the parameters which just got parsed out of the xml file. You can see this in
But long story short, you can enable hugepages in /etc/libvirt/qemu.conf (it just needs the mountpoint of your hugepages)
I’m not sure if virt-manager automatically adds this to your *.xml file, but there needs to be somewhere in the domain part (you can also define here some more options of hugepages):
<memoryBacking> <hugepages/> </memoryBacking>
you can check it in the log again, there should be
-mem-path=/dev/hugepages/* (if your mountpoint is /dev/hugepages)
Accordingly to the Arch Wiki you need to assign static hugepages if you use PCI-E passthrough (didn’t test both myself, just static)
I would need to know if there’s an actual noticeable difference between /dev/shm and /dev/hugepages before I switch over. If that bypasses QEMU’s bandwidth limitation, maybe it’s worth trying???
The next version of the host application should allow low latency 4:1 compression or use of 4:2:0 NV12 chroma.
It’s difficult to do a performance test for me, because my host card can only make 53.3 Hz and that only with 2560x1080. So my workcase doesn’t have as high memory requirements as @PetebLazar with 4K.
But you can test it yourself, only takes 5-10 minutes to set it up if you never have done it before. The only thing missing in my old post is how to set up the mountpoint and the command line options for the size of hugepages.
I did some more testing and the USB DAC works like a charm now since I passed through the whole USB controller.
Yes, don’t let QEMU handle the USB, passthrough an entire controller to the VM.
I passed through USB KB/MS, USB SND, USB LAN to every GuestOS.
Older games (F.E.A.R. 3 for example) allows UPS [email protected] on max. settings (GTX 1080Ti load ~60%).
I just got a very weird problem. On Fedora 27, everything worked fine, but when I moved to Fedora 28, the Looking Glass client runs for a short period of time and then the image gets stuck. I’ve noticed, that one of the reasons is the window losing focus, but it’s not the only case. Tried with and without spice and found out that mouse still works, even after the image gets stuck (when spice is enabled). Tried with and without Synergy, no difference. Tried both Xorg and Wayland, no difference. Using GNOME as the window manager. Haven’t tried a different one, will do so in a minute (I’ll try XFCE and i3). Image gets rendered using Intel HD 4000 graphics.
Do you have an Intel iGPU on your host? If yes, try checking out which Mesa version do you have.
I had a similar issue on Arch, i downgraded mesa from 18.0 to 17.3 and now it works fine.
Github Link of the issue
Same problem solved by user Kabbone?
Yes, it was indeed. Now it works amazingly well.
The fix for me was
-o opengl:preventBuffer=0, because I’m too lazy to find an older version of Mesa.
I finally found some time to dig into why the Mouse freezes when using Spice. See, https://www.patreon.com/posts/18658431 for more information.
Hi. I recently heard about Looking Glass when browsing /r/VFIO and I’m really interested. As someone who tried VFIO a little bit ago, I’m glad to know that soon I can make the permanent switch. (Had some issues, as well as having to switch monitor input etc.) I made an account because I have a few questions about what is actually required.
Firstly, I recall hearing that Quadro and other workstation cards has the Nvidia Capture API which allows for lower latency. I wanted to know if the Quado can only be used by the guest to be able to use the API or if it will work if I use the Quadro for the host and have a GTX 970 as the guest.
Also, if I am able to use the Quadro as the host and the GTX 970 as the guest, is it worth getting a used/refurbished Quadro K2000 over buying a new GTX 1050(ti)? (both are around $200 CAD)
No, the capturing happens on the windows side of things, so it would be needed on the guest.
Then again I’m not sure if it’s supported by now, haven’t followed for a while nevermind, it’s on the project page
There is absolutely no benefit, it’s just possible.
Is it possible to redirect the output of looking-glass-host? Since it keeps crashing for me (when changing resolution, alt-tabbing, strarting game with different ingame resolution, etc.) I’d like to log it and/or have it automatically restart based on output.