I read through the thread and tried that. Didn’t really help
I’m still stuck at this point 
I read the thread!
This is what I did
Restart linux
Ran sudo -u qemu ivshmem-server -p /tmp/ivshmem.pid -S /tmp/ivshmem_socket -l 16M -n 8
Ran VM
In the VM, ran the exe
Back on Linux, ran ./client/bin/looking-glass-client
[I] main.c:560 | run | Looking Glass (a3-0-gead48195db)
[I] main.c:636 | run | Initialized OpenGL
[E] ivshmem.c:105 | ivshmem_connect | socket connect failed
[E] main.c:711 | run | failed to connect to the ivshmem server
[W] ivshmem.c:215 | ivshmem_disconnect | socket not connected
- Windows program running with -f just seems to be waiting for something, no error message, which I think is a good thing. Sitting at Using DXGI
Do you have read/write access to /tmp/ivshmem_socket?
Damnz, had to give qemu read/write access, I’ll post a guide from the stuff I took note of.
Lemme test this stuff and report back
edit: why is the mouse not taking the input correctly, I have to click inside to update its position
@wendell Since you made your own KVM-Switch lately, how about a L1T HDMI/DP Dummy Plug with programmable EDID? Haven’t seen anything like this so far.
Right now I can only find plugs for up to 4K 60Hz although I can’t tell if simply adding a custom resolution could give us 144 Hz refresh rate as well. As long as Looking Glass can pick up the signal it basically doesn’t matter wether or not the monitor can output a custom resolution or refresh rate, right?
One step ahead of you. programmable edid is asking a bit much but cramming on a ton of modes on the eeprom up to 240hz is not really a big deal. 
Its easier to built one absurd “monitor plug” with support for anything than to bother with programmability
one thing, though, idk how/if hdcp will be a thing. that’s the rub.
this is a known issue, qemu is working on it, its not really the whole story on the issue, but for now we recommend passing through a separate mouse/keyboard. Relative (vs absolute of like an emulated tablet) is bugged in qemu. There are other bugs, but that’s why we didn’t really document that bit of it.
I just tried to run with fake grid k2 and fake quadro k5000, with “pro” drivers,
and looking-glass-host tries to use nvfbc and crashes with error
Service.cpp:109 Service::InitPointers Frame can exceede buffer size!
Any clues? Thanks
need to make ivshmem bigger on the host and restart everything.
It works! 
nvfbc is pretty swanky huh? we wont touch that with a 10 foot barge pole… because… nvidia. 
hopefully we’ll be on someone’s radar, someday. We only want to make things better for the users. something something tron we fight for the users?
3 Likes
Be very careful about admitting this. the NVidia License for the NVidia Capture API states
License Grant. Subject to the terms of this Agreement, NVIDIA hereby grants you a nonexclusive, non-transferable, worldwide, revocable, limited, royalty-free, fully paid-up license to during the term of this Agreement:
install, use and reproduce the software delivered by NVIDIA, make modifications and create derivative works of sample source code software delivered by NVIDIA and use documentation delivered by NVIDIA, provided that the software is executed only in NVIDIA GRID, Tesla or Quadro 2000+ hardware products that you separately obtain from NVIDIA or its affiliates, all to develop, test and service your products (each, a “Customer Product”) that are interoperable with NVIDIA GRID, Tesla or Quadro 2000+ hardware products; and
Since you’re not running on one of these you are breaking their license agreement for use of the Capture API. Just because you can doesn’t mean you wont get in trouble.
I have the Looking Glass client successfully mirroring the guest and it’s able to run at a high framerate. However, I’m running into some weird choppiness and tearing. When I was playing Black Ops III the game felt a bit choppy. I ran the Looking Glass client and guest side-by-side and it definitely felt like the Looking Glass client was a bit more choppy than the guest. I also noticed that the framerate on the client was consistently lower than the framerate of the game (monitored via Steam’s FPS counter), but only by 3-5 frames. I decided to run the UFO Frame Skip test and noticed some tearing on the client as well. Below is an image demonstrating that. Just for reference, my GPU for the guest is a 290 and my GPU on the host is Intel’s P3000 (E3-1275 iGPU). On the host I’m using i3 with compton. I see the same thing when running on the native resolution to 2560x1080 and when changing the windows resolution to 1920x1080
PS: Congratulations to everyone that has been working on this project. This technology is incredible!
That’s frame tearing, at this time there is nothing we can do about that while maintaining the low latency. Vulkan should help to resolve this when it’s ready.
3 Likes
Is there way to unlimit client fps?
It is unlimited… why do you think there is frame tearing?
The FPS on screen is the frame update rate from the guest’s capture API, NOT your local redraw rate. If you were to alter this to run flat out the performance would be terrible,
1 Like
is there anything more I can do to improve performance right now? I tried disabling mipmaps and setting the process priority in Windows
seems to vary a bit from game to game. Enabling vsync in a particular game so that it’s locked to 60fps or whatever seems to work pretty well for consistency/experience. have you tried that?
I tried GTA 5 with both vsync enabled and disabled but it didn’t make a difference because I’m often below 60 fps in that game. When Geforce Experience’s FPS counter shows around 40 fps, I had around 20 fps in the looking glass client which wasn’t a pleasure to look at at all
hmm, I wonder if double buffering would help. What hardware you running? I did a lot of our testing on higher-end hardware but I think I can maybe mess around with lower end hardware for more data points. Wizard Geoff is working on a vulkan api version which will dramatically help things I’m sure, too.