I had looking glass working with a real monitor, but since moving to the dummy plug I just get the “Failed to create D3D11 device: 0x887a0004” error. I’m not really sure what to do next to troubleshoot. The ivshmem driver is installed and working, the “generic pnp monitor” shows up as attached to the video card. Does anyone have any pointers on what to check/try next?
0x887a0004 is usually a driver problem. What is your GPU? And do you have the dummy configured as the primary display? At this time Looking Glass will try to duplicate the first display only, and if it’s a virtual device instead of your GPU it will fail due to the virtual device not supporting DXGI DD.
Got kind of an interesting situation here.
Running GTX680 for host, GTX1080 for guest, and A11 build of Looking-glass for both. Host OS is Arch, guest is the latest public build of Windows 10 (1803). Resolution is set to 3440x1440 for both host and guest, and naturally, 64mb of memory was specified in libvirt.
When not using Looking-glass and just connecting a monitor, everything runs perfectly fine with no hiccups at all, but when streaming the video via Looking-glass the following occurs.
When not running games, I notice a little bit of a stutter. As soon as I launch any game, my fps drops to probably 30 average, but often much less, while the game is in focus, HOWEVER, when the game is out of focus (another window is open) it runs as fast as it can in the background (in this case it’s WoW with approximately 80fps with my current settings).
Looking-glass is started with -sF parameters. Any idea what’s up? Haven’t found anyone with a similar issue so far
This is not supported, at current anything mugh higher then 1200p has performance problems.
FPS in what? the game? Looking Glass? Native?
Logs and screenshot(s) are worth a thousand words.
I apologize, should have started with that. Additionally, I forgot to mention last time that I’m running on kernel 4.18.7 with QEMU 3.0.0 and libvirt 4.6.0.207
In-game FPS (both with a monitor connected and/or with Looking Glass, makes no difference)
Looking Glass UPS/FPS when game is in focus
Looking Glass again, but when the game is in the background
What are you using for audio? When WoW is backgrounded I assume it’s audio is muted/stops. If your audio is not functioning properly it directly affects timing in most DirectX titles.
Other then that, I am not sure what would cause a UPS increase while backgrounded, perhaps WoW is disabling some features while it doesn’t have focus.
The root problem you have however is your resolution is just way too high for LG at this point.
I have an external DAC connected via optical, which is passed through to the VM with the entire onboard audio controller.
Wasn’t aware of the current resolution limit until you’ve mentioned it. Wendell said in his video that a the theoretical limit is 4k@300 FPS, so I hastily assumed that’s what is can currently handle. Gonna try running it at something more reasonable and report if I see any changes
Hey all,
I’ll go ahead and be that guy, making an account just to ask one question 
I just got another gt710 so I could virtualize my linux desktop, and everything went fine. What I’m confused on is how I can get LG working guest>guest. I can’t seem to get the uio device to show up in /dev/ no matter what combination of modprobe uio, modprobe kvmfr, insmod kvmfr.ko, etc I do to try and get it working. Is there a more detailed process that I’m missing? I figured that I’d have do to something on the host to get the linux guest to be able access the shared memory, but I’m totally lost on what I need to do/add.
Finally decided to attempt to jump in on Looking Glass.
I cloned the git repo, ran cmake, ran make, and it dropped looking-glass-client in the LookingGlass git directory in my home folder, not in bin.
Here’s the entire console process:
[marasm@localhost client]$ cmake /home/marasm/LookingGlass/client/
-- The C compiler identification is GNU 8.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.4.2")
-- Checking for modules 'sdl2;SDL2_ttf;gl;glu;egl;spice-protocol;fontconfig;x11;libconfig;nettle;hogweed'
-- Found sdl2, version 2.0.8
-- Found SDL2_ttf, version 2.0.14
-- Found gl, version 18.0.5
-- Found glu, version 9.0.0
-- Found egl, version 18.0.5
-- Found spice-protocol, version 0.12.14
-- Found fontconfig, version 2.13.0
-- Found x11, version 1.6.5
-- Found libconfig, version 1.5
-- Found nettle, version 3.4
-- Found hogweed, version 3.4
-- GMP libs: /usr/lib64/libgmp.so /usr/lib64/libgmpxx.so
-- Found GMP: /usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: /home/marasm/LookingGlass/client
[marasm@localhost client]$ make
Scanning dependencies of target looking-glass-client
[ 7%] Building C object CMakeFiles/looking-glass-client.dir/main.c.o
[ 14%] Building C object CMakeFiles/looking-glass-client.dir/lg-renderer.c.o
[ 21%] Building C object CMakeFiles/looking-glass-client.dir/ll.c.o
[ 28%] Building C object CMakeFiles/looking-glass-client.dir/utils.c.o
[ 35%] Building C object CMakeFiles/looking-glass-client.dir/spice/rsa.c.o
[ 42%] Building C object CMakeFiles/looking-glass-client.dir/spice/spice.c.o
[ 50%] Building C object CMakeFiles/looking-glass-client.dir/decoders/null.c.o
[ 57%] Building C object CMakeFiles/looking-glass-client.dir/decoders/yuv420.c.o
[ 64%] Building C object CMakeFiles/looking-glass-client.dir/renderers/opengl.c.o
[ 71%] Building C object CMakeFiles/looking-glass-client.dir/renderers/egl.c.o
[ 78%] Building C object CMakeFiles/looking-glass-client.dir/renderers/egl_shader.c.o
[ 85%] Building C object CMakeFiles/looking-glass-client.dir/renderers/egl_texture.c.o
[ 92%] Building C object CMakeFiles/looking-glass-client.dir/renderers/egl_model.c.o
[100%] Linking C executable looking-glass-client
[100%] Built target looking-glass-client
If I just move the client to bin where it should be, will that cause any issues? Did I do something wrong? OS is Fedora 28 Workstation.
The bin directory only exists for the older Makefile build in A11, you are building from master which is unreleased and as such the documentation has not yet been updated for it.
My use case is I’d want to be using my multiple, different size and refresh rate displays with no performance impact in windows, Including 144hz gsync support.
As I’d still use the windows VM as my main desktop, and the linux side would only be used when I need to use linux, It seems like all of my problems would be solved by having the linux host send its screen to the windows guest, essentially reversing looking glass.
I see you are working on OpenGL support, I’m not going to even pretend to understand most of the code base, but from what I’ve seen it looks like it works via a DirectX screen grabbing function, which Isnt going to work on linux (I did try wine-ing it to see what would happen, I got driver install errors as expected).
Would absolutely love to see support for my usecase, as it would let me move from having windows on bare metal.
At this time, there is absolutely no incentive to port the host application to Linux, the goal of this project is to allow Linux to become your primary OS and allow access to Windows for Legacy programs.
If someone decides to write a KVMFR host for Linux, they are welcome to, but it is unlikely to ever be an official part of Looking Glass.
Yeah, I can understand that, I’ve set up a cheap Pentium second PC so I can have a Linux desktop and a windows desktop without any of the compromises that exist with running windows in a VM. Just figured I’d post it here as suggested Incase anyone felt like one hell of a challenge.
Why wouldn’t you just use the Windows subsystem for Linux for your windows box?
You could look at Newtek NDI and Spice over a LAN or Synergy for something like that. NDI is pretty low latency if setup properly.
Not sure if I should do this here or on github, but I have been testing the last few additions you did on the master branch (I first updated it on October 4, then October 10). For both cases I started to notice some delay on frames being delivered to the client.
The way I perceive this is through mouse interaction: keep moving the mouse in circles and my movement doesn’t match what is on the screen anymore, I get up to 3 seconds of delay.
It when I stop moving the mouse, everything catches up and is synchronized again. I can usually replicate this if the mouse cursor change shape while moving it very fast in that circular movement.
Curious part is, the delay is only related to the mouse cursor plotting, I have a clock with the seconds going down and it is completely in sync between host and guest.
This is happening for me with a nvidia 1080. Let me know if you need more info or if I should open up something on github instead (kind of too vague for gh I think).
+1 also noticed this. Haven’t had time to bisect specific commit.
Does this occur when you use the EGL renderer?
looking-glass -g egl
Edit: Scratch that… There were some changes made to improve mouse sync with the client, one of which is to always feed back the mouse position even when DXGI doesn’t capture it.
Let me have a bit of a dig into the changes and see if I can spot why this might be occurring. If you could provide details on your mouse setup it would help.
One of the changes pushes mouse updates into a queue to ensure they are not missed, as a dropped mouse update may cause the cursor icon to be incorrect, or visible/invisible when it shouldn’t be. If this queue backs up it could explain the behaviour you’re seeing. I may need to take another approach and accumulate the updates instead of queuing them.
Please also provide the output from the client.
I just pushed in an update that implements cursor update accumulation, this should both be faster and will prevent the cursor lag you were experiencing. This is a host only update, no need to rebuild the client.
Edit: There were still some bugs in this code that have been fixed, be sure to fetch the latest version.
Much better after the recent changes. 
1 Like