gnif / lookingglass Goto Github PK

As soon as I catch the courser, the mouse movement stops for some seconds, then stutters heavily.

This error gets printed:

[E] spice.c:826 | spice_mouse_motion | mouse motion ringbuffer full!
[E] main.c:567 | eventThread | SDL_MOUSEMOTION: failed to send message

I tried differnent sizes for:

#define SPICE_MOUSE_QUEUE_SIZE 32

setting higher values stopped the mouse movement for a longer time, then prints the error and stutters

setting lower values let the error occur sooner

I use a10.
I also tried building the latest commit but the libraries on Debian are to outdated.
Looking-glass worked nearly flawlessly on my Arch installation.

Required information

Host CPU: Intel Core i7-4770 CPU @ 3.9GHz
Host GPU: Mesa DRI Intel(R) Haswell Desktop
Guest GPU: NVIDIA GeForce 780ti
Host Kernel version: x86_64 Linux 4.9.0-6-amd64
Host QEMU version: version 2.8.1(Debian 1:2.8+dfsg-6+deb9u3)

OS: Ubuntu 17.10
Install state: Clean install + build-essential

Problem Description:

The provided information on : Compile LookingGlass from sources on ubuntu is missing some dependencies in order to compile properly LookingGlass from source.

Errors + Solutions:

Package libva was not found in the pkg-config search path.

sudo apt-get install libva-dev

main.c:37:10: fatal error: libconfig.h: No such file or directory

sudo apt-get install libconfig-dev

spice/spice.c:40:10: fatal error: spice/protocol.h: No such file or directory

sudo apt-get install libva-dev

New one liner for the documentation

sudo apt-get install git libsdl2-dev libsdl2-ttf-dev libssl-dev libspice-protocol-dev libfontconfig1-dev libx11-dev fonts-freefont-ttf libva-dev libconfig-dev build-essential

This new one liner should avoid people asking question why it doesn't compile :)

Feel free to close the issue if this doesn't apply for any reason.

Hi, I have problem with building client on Gentoo with gcc 6.4.0 and 7.2.0, but when I use gcc 5.4.0 client is build correctly.

gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/spice-1 -DBUILD_VERSION='"a10-15-g9000fdf6fc"' -o .build/main.o main.c
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/spice-1 -DBUILD_VERSION='"a10-15-g9000fdf6fc"' -o .build/lg-renderer.o lg-renderer.c
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/spice-1 -DBUILD_VERSION='"a10-15-g9000fdf6fc"' -o .build/spice/spice.o spice/spice.c
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/spice-1 -DBUILD_VERSION='"a10-15-g9000fdf6fc"' -o .build/decoders/null.o decoders/null.c
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/spice-1 -DBUILD_VERSION='"a10-15-g9000fdf6fc"' -o .build/decoders/h264.o decoders/h264.c
decoders/h264.c: In function ‘lgd_h264_initialize’:
decoders/h264.c:199:7: error: ‘VAProfileH264Baseline’ is deprecated [-Werror=deprecated-declarations]
       VAProfileH264Baseline,
       ^~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/x86_64-pc-linux-gnu/va/va_glx.h:28:0,
                 from /usr/include/va/va_glx.h:10,
                 from decoders/h264.c:28:
/usr/include/va/va.h:345:5: note: declared here
     VAProfileH264Baseline va_deprecated_enum = 5,
     ^~~~~~~~~~~~~~~~~~~~~
decoders/h264.c:222:3: error: ‘VAProfileH264Baseline’ is deprecated [-Werror=deprecated-declarations]
   vaGetConfigAttributes(this->vaDisplay, VAProfileH264Baseline, VAEntrypointVLD, &attrib, 1);
   ^~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/x86_64-pc-linux-gnu/va/va_glx.h:28:0,
                 from /usr/include/va/va_glx.h:10,
                 from decoders/h264.c:28:
/usr/include/va/va.h:345:5: note: declared here
     VAProfileH264Baseline va_deprecated_enum = 5,
     ^~~~~~~~~~~~~~~~~~~~~
decoders/h264.c:229:3: error: ‘VAProfileH264Baseline’ is deprecated [-Werror=deprecated-declarations]
   status = vaCreateConfig(this->vaDisplay, VAProfileH264Baseline, VAEntrypointVLD, &attrib, 1, &this->vaConfigID);
   ^~~~~~
In file included from /usr/include/x86_64-pc-linux-gnu/va/va_glx.h:28:0,
                 from /usr/include/va/va_glx.h:10,
                 from decoders/h264.c:28:
/usr/include/va/va.h:345:5: note: declared here
     VAProfileH264Baseline va_deprecated_enum = 5,
     ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:31: .build/decoders/h264.o] Error 1

I've been seeing a pretty large performance hit with VR applications when looking glass is running.

Since the output of the display is not relevant while doing VR it would be nice to have a keyboard shortcut that can be used to suspend/resume the looking glass host to get rid of the performance overhead while running VR

You should add a no video argument "-S" for exemple
so it acts as a spice client only the advantage over virt-viewer being a way smoother mouse for some reason and keyboard much more responsive overall
also seamless integration with the linux desktop (quit with the mouse)
i don't know why but you made that really well
and another issue being virt-viewer not scaling corectly because it don't know the res

But you should also add a key combinason (setable) to toggle video on the go if it haven't been passed as an argument because it dramatically slow down performance on some case
(example being latency in ossu mania (a rythm game) going from 0.30ms withouth looking glass to 1ms with looking glass)

Also a thing to fix is keyboard locking (as an option)
on bspwm (my windows manager)
i can exit looking glass with my WM shortcuts which is anoying for example if i press ALT-TAB it don't alt tab on windows but change focus on my wm

And last but not least being able to change the shortcut to stop keyboard locking and mouse locking (individualy if possible)

Also looking glass have a noticeable latency compared to using another screen directly
maybe that's because i have an old gpu (gtx670)

so generaly i use windows on main screen and use looking glass as a spice client but i passthrough the mouse and keyboard for osu mania because looking glass video adds latency just shutting video would fix that
but toggling it back is usefull when i just use it as a working station

sorry for the long post and thanks for reading ^^

Perhaps the host application should capture audio and send that back to the client also, thus bypassing Qemu's rather lacklustre audio implementation.

One could argue that this would be a kludge and that Qemu's audio should be fixed; while true I would argue the ability to receive the audio without running it through an emulated sound device is a worthy feature in its own right.

Handling both audio and video will also come in handy for other use cases like the inevitable OBS plug-in.
My extremely quick look into audio capture on windows shows that it might involve interacting with the sound "hardware" anyway, but keep in mind that our GPU's have audio hardware too.

Required information

Host CPU: i5-6600
Host GPU: hd530 1gB
Guest GPU: rx480 4gB
Host Kernel version: 4.16.5-1-ARCH
Host QEMU version: /usr/bin/qemu-system-x86_64 --version

My log:
https://i.imgur.com/RjuVzUt.png
When I try to connect via Looking Glass client, system just freeze and I must restart Windows VM and there is no other way to get rid of it. I tried like multiple methods to fix that, I even compiled newest client or tried to tweak spice and nothing works.
https://i.imgur.com/9EW3kyK.png //It even sometimes works for like 2-4 seconds, I can move mouse and freeze. In that moment I can't even close looking-class-cient properly and I must xkill it.

Required information

Host CPU: NA
Host GPU: NA
Guest GPU: NA
Host Kernel version: 4.13.0-37-generic
Host QEMU version: NA

Hopefully this is the right place to report this, but the page Building The Looking Glass Client from Source at
https://looking-glass.hostfission.com/node/6 is missing two required dependencies libconfig-dev and libva-dev

looking-glass-client -s -M -k
[I] main.c:560 | run | Looking Glass (a3-3-gcd54cb179b)
[I] main.c:636 | run | Initialized OpenGL
[I] ivshmem.c:153 | ivshmem_connect | RAM Size : 67108864
[I] main.c:762 | run | Waiting for host to signal it's ready...
[I] main.c:766 | run | Host ready, starting session
[I] main.c:235 | renderThread | Data Format: w=2560, h=1440, s=2560, p=10240, bpp=32
[I] opengl.c:159 | lgr_opengl_configure | Vendor : X.Org
[I] opengl.c:160 | lgr_opengl_configure | Renderer: Radeon RX 550 Series (AMD POLARIS12 / DRM 3.18.0 / 4.13.12-1-vfio, LLVM 5.0.0)
[I] opengl.c:161 | lgr_opengl_configure | Version : 3.0 Mesa 17.2.6
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list https://discourse.libsdl.org/ X11 KeyCode 204 (196), X11 KeySym 0x0 ((null)).

The, usually blue, busy circle of window is colored in orange. I can't make out any other color shifts so far. It's not color shifted on the guest monitor. Sorry for the crappy quality of the screenshot.

Whenever I try to start the client with the parameter -F (Borderless fullscreen mode) it freezes immediately (so the only thing I can do is force-close it). I use additional parameters, which work without '-F': "-k -o opengl:mipmap=0 -n -s -d -w 3440 -b 1440".

Side info: In the frozen state it displays a static image of windows-vm und the FPS counter shows 0.0002 for both measurement.

System Info

Host CPU: Intel® Core™ i7-4790K
Host GPU: Intel® HD-Grafik 4600
Guest GPU: NVIDIA GeForce GTX 780
Host Kernel version: 4.13.0-21 (Ubuntu 17.10)
Host QEMU version: QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.1)

Love the project and I hope we can fix it!

./looking-glass-client -s
[I] main.c:560 | run | Looking Glass (a3-2-g973ad5e2b0)
[I] main.c:636 | run | Initialized OpenGL
[I] ivshmem.c:153 | ivshmem_connect | RAM Size : 16777216
[I] main.c:762 | run | Waiting for host to signal it’s ready…
[I] main.c:766 | run | Host ready, starting session

On host with -f, crash:

Service.cpp:270 Cursor shape size exceeds buffer size

Changing DPI to 100% it works.

Is there any plans for mouse/audio stuff?
Or this project will work only with video streaming?
Windows 10 has https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/virtual-hid-framework--vhf-
and old project https://github.com/djpnewton/vmulti available. This can be used to emulate mouse and keyboard.

Required information

Host CPU: Intel i7-6700K
Host GPU: Intel HD Graphics 530
Guest GPU: GTX 980 Ti
Host Kernel version: 4.16.4-1-MANJARO
Host QEMU version: 2.11.1
Guest Windows version: Windows 10 RS4/1803

Issue

After a fresh install of Windows 10 Looking glass cannot run because of following System Errors:

The code execution cannot proceed because VCRUNTIME140.dll was not found. Reinstalling the program may fix the problem.

and

The code execution cannot proceed because MSVCP140.dll was not found. Reinstalling the program may fix the problem.

Solution

After downloading and installing of Microsoft Visual C++ 2015 Redistributable (x64) - 14.0.23026 the problem was fixed and looking-glass-host executable run fine. Uninstalling this package again confirms that this is indeed the change that fixed this issue.

Recommendation

Document the Microsoft Visual C++ 2015 Redistributable (x64) dependency.

Required information

Host CPU: i7-5930K
Host GPU: GTX 970
Guest GPU: GTX 760
Host Kernel version: 4.14.3-1-ARCH
Host QEMU version: 2.10.1

When using the looking-glass-client in -F fullscreen mode on a multi-monitor host setup; the mouse min/max boundaries will drift when switching between client and host. A temporary fix for this might be to have an option on the client to eat all mouse input until a hotkey is pressed. Similar to how virt-viewer / virt-manager works if you fullscreen. Requiring shift+f6 or the control+alt key to be pressed.

I am presently working on a LG like client in Rust(I am more comfortable in this language than I am C++ and taking advantage of the third party libraries(crates)). Currently I am reading in frame updates from the LG server shared memory output, with no current plans for supporting more advanced formats like h264, nor SPICE(though I may try add that at a later date). After I will work on a server component that can support Linux VMs.

I have two questions so far:

1. You are setting a compositor bypass hint here. SDL sets this by default, is it necessary? The specs also define it as _NET_WM_BYPASS_COMPOSITOR, xprop can be used to verify this information. Your code is adding NETWM_BYPASS_COMPOSITOR(CARDINAL) = 1, is there some X11 implementation where they've implemented the spec incorrectly to read this property instead of the correct one, or was this a mistake on your part?

2. I'm not familiar enough with OpenGL to review the renderers yet. I've got a Client working that displays the frames by using SDLs canvas with updating a texture with each frame, copying to the canvas and presenting. I see you've gone a more direct/low-level route, how beneficial is that over the simple approach I'm presently going with?

I recently built on Ubuntu 17.10 and had to make some modifications to get the Makefile to work.

The following changes were necessary to the Makefile:

diff --git a/client/Makefile b/client/Makefile
index 00549d8..8100de1 100644
--- a/client/Makefile
+++ b/client/Makefile
@@ -1,5 +1,5 @@
 BINARY  = looking-glass-client
-CFLAGS  = -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING
+CFLAGS  = -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -I/usr/include/spice-1 -DDEBUG -DATOMIC_LOCKING
 LDFLAGS = -lrt
 
 CFLAGS  += -ffast-math

I also had to install libva-dev as the dependency was missing.

Hey! Great work on the software, I've been needing something like this so bad.

As the default opengl code seems to bottleneck me quite heavily, I tried pulling out all the fancy persistent buffer mapping and replacing it with a simple glTextImage2D with a stride, like this:

glPixelStorei(GL_UNPACK_ROW_LENGTH, this->format.stride);
  glTexImage2D(
    GL_TEXTURE_2D,
    0,
    this->intFormat,
    this->format.width,
    this->format.height,
    0,
    this->vboFormat,
    GL_UNSIGNED_BYTE,
    data
  );

I thought I would share my findings, as it has increased the throughput of lookingglass a lot on my setup.

EDIT:
Thought it might be prudent to share what kind of hardware I'm running on to see these results.

CPU: i5-6600k
RAM: 4x8GB Kingston HyperX Fury DDR4-2133
Host GPU: RX 580
VM GPU: GTX970

Hi, I have a problem while trying to compile the code. gcc gives me this error:

spice/spice.c: In function ‘spice_connect’:
spice/spice.c:136:3: error: ‘strncpy’ specified bound 32 equals destination size [-Werror=stringop-truncation]
   strncpy(spice.password, password, sizeof(spice.password));
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.

I'm only a novice at programming so I'm sorry if this is something I should've figured out myself. From what I found out on google this seems to have to do with gcc 8 (my gcc version is 8.0.1) buffer overflow checking.

Required information

Host CPU: i5 6600k
Host GPU: integrated graphics
Guest GPU: 1060 gtx
Host Kernel version: 4.14.11-1-ARCH
Host QEMU version: 2.11.0

Hello. I have strange problem with plasma and client application. As i uderstand sometimes when i switch off my virtual machine, my plasma window manager gets broken. Like i have no any window manager at all. All windows are working, but i can't for example switch between them. Maybe you know what it can be? I run Windows 10 guest, and Arch host.
I use such command:
~/Downloads/LookingGlass/client/bin/looking-glass-client -F -f /tmp/ivshmem_socket -s

should be #define WIN32_LEAN_AND_MEAN
I only saw one instance in the shared memory implementation, don't know how many there are.

Hey,

I'm not sure how to word this properly, so it might get a bit confusing, but I've seen in the IRC channel that you prefer relative mouse positioning (for an understandable reason). However, can a feature of absolute positioning at least be added as a non-default argument? If the mouse in the guest moves for any reason, the host and guest cursors are no longer aligned (This means window snapping, evdev, passed through USB devices, etc. For example, right click the start button with the host cursor shown, the cursors will become slightly out of sync.) In cases of the two cursors being largely out of sync, looking glass is nearly unusable. I read that absolute positioning was "No longer needed" with a11, but I noticed immediately that this wasn't the case. I can't seem to get the guest cursor to snap to the edge of the screen that the window was entered on, but even if it did snap to the edge, the cursor could still become out of sync if the cursor snaps, which happens a lot since I have windows warp the cursor to the default button for all new windows.

Host CPU: Intel(R) Core(TM) i7-5960X CPU @ 3.00GHz
Host GPU: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X]
Guest GPU: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1)
Host Kernel version: 4.13.5
Host QEMU version: qemu-2.11.1

upgrading mesa to 18.0.0-rc4 causes the looking-glass client to "freeze" after the first event: keyboard, mouse button, or window. mouse movement works as expected. the program is not strictly frozen and appears to continue processing events properly but the graphics stop updating. In this state the client no longer responds to a standard close event and must be killed with SIGKILL.

reverting to mesa 17.2.8 corrects all these issues

Host CPU: i7-4800MQ
Host GPU: Intel HD Graphics 4600
Guest GPU: Quadro K1100M
Host Kernel version: 4.14.6-xanmod9
Host QEMU version: QEMU 2.11.0

When trying to switch users, and then returning to the user from which the Looking Glass host was started, Looking Glass will crash with:

[I] CaptureFactory.h:83 | CaptureFactory::DetectDevice | Trying NvFBC
[E] NvFBC.cpp:130 | Capture::NvFBC::Initialize | Failed to create an instance of NvFBC
[I] CaptureFactory.h:83 | CaptureFactory::DetectDevice | Trying DXGI
[I] CaptureFactory.h:86 | CaptureFactory::DetectDevice | Using DXGI
[I] Service.cpp:235 | Service::Process | ReInitialize Requested
[E] DXGI.cpp:100 | Capture::DXGI::Initialize | Failed to locate a valid output device
[E] Service.cpp:238 | Service::Process | ReInitialize Failed

Tried to provide the dump file however it was not created?

looking-glass-client -s -M -k
[I] main.c:560 | run | Looking Glass (a3-3-gcd54cb179b)
[I] main.c:636 | run | Initialized OpenGL
[I] ivshmem.c:153 | ivshmem_connect | RAM Size : 67108864
[I] main.c:762 | run | Waiting for host to signal it's ready...
[I] main.c:766 | run | Host ready, starting session
[I] main.c:235 | renderThread | Data Format: w=2560, h=1440, s=2560, p=10240, bpp=32
[I] opengl.c:159 | lgr_opengl_configure | Vendor : X.Org
[I] opengl.c:160 | lgr_opengl_configure | Renderer: Radeon RX 550 Series (AMD POLARIS12 / DRM 3.18.0 / 4.13.12-1-vfio, LLVM 5.0.0)
[I] opengl.c:161 | lgr_opengl_configure | Version : 3.0 Mesa 17.2.6
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list https://discourse.libsdl.org/ X11 KeyCode 204 (196), X11 KeySym 0x0 ((null)).

There is an "invisible" visible triangle in the upper right corner when you're moving a window through the area. While it's not a critical bug, if it actually is one, it's not nice to see.

Attached screenshots. I made a video where it's many times better to see it on but I don't know what the way to share it on github is.

gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/spice-1 -DBUILD_VERSION='"a3-2-g973ad5e2b0-dirty"' -o .build/main.o main.c
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/spice-1 -DBUILD_VERSION='"a3-2-g973ad5e2b0-dirty"' -o .build/spice/spice.o spice/spice.c
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -ffast-math -fdata-sections -ffunction-sections -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/libdrm -I/usr/include/freetype2 -I/usr/include/spice-1 -DBUILD_VERSION='"a3-2-g973ad5e2b0-dirty"' -o .build/ivshmem/ivshmem.o ivshmem/ivshmem.c
ivshmem/ivshmem.c: In function ‘ivshmem_wait_irq’:
ivshmem/ivshmem.c:514:7: error: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Werror=unused-result]
       read(fd, &kick, sizeof(kick));
       ^
cc1: all warnings being treated as errors
Makefile:28: recipe for target '.build/ivshmem/ivshmem.o' failed
make: *** [.build/ivshmem/ivshmem.o] Error 1

Removing the -Werror flag can make it work. And the client work without any problem so far. No sure this warning will have any impact in the future.

Compile with gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609

Not sure if this is the correct place for the issue, but the SSL certificate has expired on https://looking-glass.hostfission.com/

Issued On	Monday, 11 December 2017 at 09:27:34
Expires On	Sunday, 11 March 2018 at 09:27:34
SHA-256 Fingerprint	10 3E 15 D3 C3 C3 5F 2E EA DD 71 4C A9 50 95 7D B6 CA EB 26 25 DF EB FD AE 96 7D 78 86 F8 28 41
SHA-1 Fingerprint	DA 79 8E 1C 71 C2 02 99 0A 9F B3 47 E3 A4 A7 54 03 22 74 3B

Required information

Host CPU: Intel Core i5-6500
Host GPU: iGPU
Guest GPU: ASUS STRIX-GTX950-DC2OC-2GD5-GAMING, 2GB
Host Kernel version: Manjaro (base Archlinux), Kernel 4.16.7-1
Host QEMU version: 2.12.0-1

Description of problem:

The looking-glass-client application ending immediately after starting.

Steps to Reproduce:

1.) Start guest "qemu-system-x86_64 -machine pc-q35-2.11,accel=kvm ... -drive if=pflash,format=raw,readonly,file=./OVMF_CODE-pure-efi.fd ... -global ICH9-LPC.disable_s4=0 ..."
2.) looking-glass-client -p 5902 -F (It works well.)
3.) Hibernate guest (S4)
4.) Reset host
5.) Start guest
6.) looking-glass-client -p 5902 -F
The following information is displayed:

[I]               main.c:697  | run                            | Looking Glass (a10-35-g3d9d275d61)
[I]               main.c:698  | run                            | Locking Method: Atomic
[I]               main.c:691  | try_renderer                   | Using Renderer: OpenGL
[I]               main.c:779  | run                            | Using: OpenGL
[I]               main.c:897  | run                            | Waiting for host to signal it's ready...
[I]              spice.c:341  | spice_on_common_read           | notify message: keyboard channel is insecure
[I]               main.c:901  | run                            | Host ready, starting session
[E]               main.c:906  | run                            | Invalid header magic, is the host running?

Actual results:

The looking-glass-client app closes.

I have to reset Looking-glass-host.exe.

I felt the lack of a troubleshooting FAQ. Here are a few minor documentation points that would've really helped me get going, as of Alpha-7, phrased for possible inclusion in a FAQ or troubleshooting guide.

• Any kind of permission error probably means your qemu process is running as other than your login user. [This is documented.]
• Your guest GPU almost certainly supports DXGI. The server-side (guest) probing error "Capture is not possible, unsupported device or driver" indicates NVidia duplication has failed, not that DXGI has failed. You can make the error go away by specifying a "-c" option.
• The server log does not show any indication of client connections, so don't expect any.
• If your client hangs at "Waiting for host to signal it's ready...", you likely have a communication issue between the client and server.
• Display Spice is not strictly necessary, but without it, you cannot send mouse/keyboard from the host to the guest.

And one comment directly to the authors:

• The guest-side application is called "host". This is confusing in the context of virtualization. Suggest you change this nomenclature to "server" to make it clear that it pairs with the host-side client.

Required information

Host CPU: i5-4690K
Host GPU: Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
Guest GPU: Nvidia GTX 760
Host Kernel version: 4.13.0-19-generic
Host QEMU version: QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3)

Host CPU: AMD Ryzen 2400G
Host GPU: AMD Ryzen 2400G
Guest GPU: Sapphire Radeon RX 580
Host Kernel version: 4.17-rc7
Host QEMU version: version 2.12.0 (Debian 1:2.12+dfsg-3)

LG host behaves like the SSE issue is described, but SSE seems to be enabled (PCSX2 works with SSE2 enhancements enabled). Is there any more reliable way to test if SSE is the issue rather than just "LG silently crashes"? Guest is running on core2duo vcpus for compatibility reasons, I might be able to set up a test machine with host-passthrough vcpus later today.

I managed to capture a screenshot just before the crash here.

Alpha 10 works flawlessly and performs well at 1080p, if this turns out to be SSE related is there any chance we can get back the generic memcpy() implementation behind a compile flag? I don't have a Windows compatible build environment and I doubt I'll have time to set it up until next weekend.

No looking-glass-host.dmp file is created which I presume means a hard crash.

Required information

Host CPU: Ryzen 2700x
Host GPU: AMD 580 8GB
Guest GPU: Nvidia 1080
Host Kernel version: 4.16.11-300.fc28.x86_64
Host QEMU version: 2.11.1

I cannot seem to build a11 it errors with the following logs:

Package nettle was not found in the pkg-config search path.
Perhaps you should add the directory containing `nettle.pc'
to the PKG_CONFIG_PATH environment variable
Package 'nettle', required by 'virtual:world', not found
Package 'hogweed', required by 'virtual:world', not found
cc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -Wfatal-errors -D USE_NETTLE  -DBUILD_VERSION='"a11-0-g97749b335a"' -o .build/main.o main.c
Package nettle was not found in the pkg-config search path.
Perhaps you should add the directory containing `nettle.pc'
to the PKG_CONFIG_PATH environment variable
Package 'nettle', required by 'virtual:world', not found
Package 'hogweed', required by 'virtual:world', not found
cc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -Wfatal-errors -D USE_NETTLE  -DBUILD_VERSION='"a11-0-g97749b335a"' -o .build/spice/rsa.o spice/rsa.c
spice/rsa.c:23:10: fatal error: spice/protocol.h: No such file or directory
 #include <spice/protocol.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:46: .build/spice/rsa.o] Error 1

However building a10 works perfectly fine:

gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -I/usr/include/SDL2 -D_REENTRANT -I/usr/include/libdrm -I/usr/include/spice-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid  -DBUILD_VERSION='"a10-0-g59fa025292-dirty"' -o .build/spice/spice.o spice/spice.c
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -DATOMIC_LOCKING -ffast-math -fdata-sections -ffunction-sections -I/usr/include/SDL2 -D_REENTRANT -I/usr/include/libdrm -I/usr/include/spice-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid  -DBUILD_VERSION='"a10-0-g59fa025292-dirty"' -o .build/renderers/opengl.o renderers/opengl.c
gcc -o bin/looking-glass-client .build/main.o .build/lg-renderer.o .build/spice/spice.o .build/renderers/opengl.o -lrt -Wl,--gc-sections -lSDL2_ttf -lSDL2 -lGLU -lGL -lssl -lcrypto -lfontconfig -lfreetype -lX11 

Any ideas?

Required information

Host CPU: Ryzen 7 1700x
Host GPU: Asus Strix RX 460
Guest GPU: Sapphire RX Vega 56
Host Kernel version: 4.14.8
Host QEMU version: 2.11.0

Bug

The mouse cursor on the windows guest often runs into invisible borders where it can't be moved any further in that direction. Going back and towards the border again allows to "push through" the border but even that is not working 100% of the time. I'm running the looking glass window as windowed fullscreen.

Host CPU: Intel Xeon CPU E5-1650 v3 @ 3.50GHz
Host GPU: NVIDIA GeForce GTX 980 Ti
Guest GPU: NVIDIA GeForce GTX 1080 Ti
Host Kernel version: 4.14.5-1-ARCH
Host QEMU version: 2.10.1
looking-glass-client version: commit 49acc6e
looking-glass-host version: release a7

21:9 Aspect ratio monitor

Trying to get spice keyboard/mouse input working. Have tried all combinations of the looking-glass-client "-j Disable cursor position scaling" option and the Windows mouse acceleration registry fixes here applied and un-applied.

The issue I'm seeing is that the mouse cursor halts its horizontal or vertical movement against an invisible wall. This is very consistently reproducible with Windows mouse acceleration disabled, and can be reproduced with mouse acceleration enabled if the mouse is moved slowly.

With mouse acceleration disabled, it seemed to me at first that the cursor was stuck inside a 16:9 box on my 21:9 monitor; as if some assumption about aspect ratio was being made somewhere in the stack. However, with further investigation I was able to reproduce the problem with vertical movement as well.

As title says, it basically stays mostly as Windows default cursor and it does not change in games.

After a pleasent experience getting this to run on debian I thought i might as well just package it. But there are some issues:
As it is right now technically Looking Glass can't be redistributed by distributions (looking at you Arch) or in any form really. With the software being licensed as GPL and the client linking against OpenSSL you run into the common licensing issue between the two. As they are not compatible without granting an exception.
Check out https://people.gnome.org/~markmc/openssl-and-the-gpl.html & https://lists.debian.org/debian-legal/2004/05/msg00595.html
You can simply add an exception to the current licensing, solving the issue.

Another licensing issue is the use of the vendor/getopt files. These don't really affect me and the debian packaging but also cause the host application to be impossible to be redistributed as the BSD-4-clause of the old minix project and GPL clash https://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_(original_"BSD_License")
This isn't really an issue though as you can just replace the getopt files with the current ones from the minix project which have been in public domain for quite a while. (https://github.com/Stichting-MINIX-Research-Foundation/minix/blob/master/usr.bin/getopt/getopt.c)

Will linux guest support be added to this project?

So I have finally found the time to take a look into the project, and ended up creating a package in the Open Build Service for my own convenience.

Soon after I had it all working, however the requirement/suggestion to have /dev/shm/looking-glass be created upon boot or manually had me thinking.

Libvirt allows the use of hooks to run before VM startup/ after Shutdown, etc...

in the file: /etc/libvirt/hooks/qemu

#!/bin/bash
if [ "${1}" = "VM_NAME" ]; then
        if [ "${2}" = "start" ] || [ "${2}" = "reconnect" ]; then
                /bin/touch /dev/shm/looking-glass-${1}
                /bin/chown qemu:users /dev/shm/looking-glass-${1}
                /bin/chmod 660 /dev/shm/looking-glass-${1}
        fi
        if [ "${2}" = "stopped" ] || [ "${2}" = "reconnect" ]; then
                /bin/rm /dev/shm/looking-glass-${1}
        fi
fi

This can be defined any number of times, allowing multiple VMs to have their shared memory managed in an automated way.

Required information

Host CPU: Ryzen 1700
Host GPU: AMD RX560
Guest GPU: Nvidia 1070
Host Kernel version: 4.17.0-041700rc3-generic
Host QEMU version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7)

Hello,

Decided to try LG again as it worked fine few months back, however now I am facing several problems.
My setup changed quite a bit (software wise) and this might be at fault.

Here is the description, any help is welcome.
The GL window is black (except for fps information that is displayed properly (60fps, ~3.99 UPS)
What versions of LG have I tried:

• a10
• git master (by the way there is an incompatible pointer error with h264 decode, couldn't figure it out, so just compiled the bin without h264 support)

What does my setup look like:

• Standard default ubuntu 18.04 install
• Last kernel from mainline (this also fails with older "stable" kernels)
• 3 screens (2 host (1920x1200, 3840x2160), 1 guest 1200x1920)
• The guest screen is setup vertically

Does LG guest or host crash ? NO
Does LG connect to host to guest ? YES
Have you tried different memory allocation size ? YES (more than enough for that guest res@24bit

Some logs:

./looking-glass-client -a -k -j
[I] main.c:682 | run | Looking Glass (a10-59-gda2bcfdf9a-dirty)
[I] main.c:683 | run | Locking Method: Atomic
[I] main.c:676 | try_renderer | Using Renderer: OpenGL
[I] main.c:764 | run | Using: OpenGL
[I] main.c:879 | run | Waiting for host to signal it's ready...
[I] spice.c:347 | spice_on_common_read | notify message: keyboard channel is insecure
[I] main.c:883 | run | Host ready, starting session
[I] main.c:174 | updatePositionInfo | client 1200x1920, guest 1200x1920, target 1200x1920, scaleX: 1.00, scaleY 1.00
[I] main.c:174 | updatePositionInfo | client 1024x768, guest 1200x1920, target 480x768, scaleX: 2.50, scaleY 2.50
[W] main.c:177 | updatePositionInfo | Window size doesn't match guest resolution, cursor alignment may not be reliable
[I] opengl.c:545 | configure | Vendor : X.Org
[I] opengl.c:546 | configure | Renderer: Radeon RX 560 Series (POLARIS11 / DRM 3.25.0 / 4.17.0-041700rc3-generic, LLVM 6.0.0)
[I] opengl.c:547 | configure | Version : 3.0 Mesa 18.0.0-rc5
[I] opengl.c:557 | configure | Using GL_AMD_pinned_memory
[I] opengl.c:592 | configure | Using decoder: NULL
[I] main.c:174 | updatePositionInfo | client 1200x1920, guest 1200x1920, target 1200x1920, scaleX: 1.00, scaleY 1.00

Once I click scroll lock to get the mouse to move on the guest (The mouse only moves If I click anywhere inside the LG window otherwise, there is no mouse position matching).

[W] spice.c:410 | spice_on_main_channel_read | main channel unhandled message type 105
[I] main.c:516 | eventFilter | Server Mode: on
[I] main.c:516 | eventFilter | Server Mode: off
[W] spice.c:410 | spice_on_main_channel_read | main channel unhandled message type 105

If you want me to do anything or test with a different setup, let me know, I'll gladly provide extra feedback.

Concerning the black screen, it seem the texture is not being pushed to the GL surface you create in LG.
Concerning the mouse, I don't see why the spice client doesn't follow the mouse when the window is active but no scroll lock is in place (click updates the to the correct position tough), and I certainly don't see why the cursor is "reset" back to its original place (when you first press scroll lock) after a click if the scroll lock was activated.

I had one run, where I got the following. But I am unable to reproduce:

[E] spice.c:854 | spice_mouse_motion | mouse motion ringbuffer full!
[E] main.c:497 | eventFilter | SDL_MOUSEMOTION: failed to send message
[E] spice.c:854 | spice_mouse_motion | mouse motion ringbuffer full!
[E] main.c:497 | eventFilter | SDL_MOUSEMOTION: failed to send message
[I] main.c:174 | updatePositionInfo | client 1200x1920, guest 1200x1920, target 1200x1920, scaleX: 1.00, scaleY 1.00
[E] spice.c:854 | spice_mouse_motion | mouse motion ringbuffer full!
[E] main.c:497 | eventFilter | SDL_MOUSEMOTION: failed to send message
[E] spice.c:854 | spice_mouse_motion | mouse motion ringbuffer full!
[E] main.c:497 | eventFilter | SDL_MOUSEMOTION: failed to send message
[E] spice.c:854 | spice_mouse_motion | mouse motion ringbuffer full!
[E] main.c:497 | eventFilter | SDL_MOUSEMOTION: failed to send message
[E] spice.c:854 | spice_mouse_motion | mouse motion ringbuffer full!

Qemu has a "no-quit" parameter. If passed, clicking on X or ALT+F4 are ignored.

It would be nice if the client could ignore ALT+F4 (or pass it to the guest) so that if I quit games, the game gets closed and not the looking client!

It'd be nice if there was a way to keep the window at the same aspect ratio as the host, to avoid the black bars and cursor annoyances.

XSizeHints should allow informing the WM about this.

Required information

Host CPU: AMD FX(tm)-8320 Eight-Core Processor
Host GPU: [AMD/ATI] Curacao XT / Trinidad XT [Radeon R7 370 / R9 270X/370X]
Guest GPU: [AMD/ATI] Cape Verde PRO [Radeon HD 7750/8740 / R7 250E]
Host Kernel version: 4.16.8
Host QEMU version: QEMU emulator version 2.12.0

Accepting other methods has two benefits:

From a security perspective, letting a TCP server run without any form of authentication is a huge security risk, because visiting any website could run commands on your computer or crash your system by contacting the TCP socket.

From a speed perspective, the alternatives are simply faster. Unix sockets have less overhead than a tcp socket on a localhost address and implementing them should be only a few lines of code.
From https://blog.myhro.info/2017/01/how-fast-are-unix-domain-sockets

The Unix socket implementation can send and receive more than twice the number of messages, over the course of a second, when compared to the IP one.

Fwiw, my system currently reports latency of around 20-50ms depending upon load when looking-glass is started.

Conceptually, the fastest method would be shovelling the data over ivshmem as well. But this is an avoidable increase in complexity when qemu is already capable of controlling the guest, so I wouldn't at all expect this to happen from a maintainability perspective just yet.

Cheers.

Required Informations:

Host CPU: Ryzen 7 1800x
Host GPU: GTX 1080 (1 out of 2)
Guest GPU: GTX 1080 (1 out of 2)
Host Kernel version: 4.14.35_1
Host QEMU version: 2.11.1

Additional Informations:

RAM: 4x F4-3300C14-8GTZR, Dual Channel, Unbuffered, 3066 MT/s
LookingGlass version: a10
Xorg version: 1.19.6
Distro: Void Linux (minimalistic, leading edge, rolling release one)
WM: cinnamon
Host GPU driver: Proprietary Nvidia with 2 Monitors in Mosaic mode.
CPU Governor; Performance

Problem

Altough the Framerates are high, The displayed image is sluggish from time to time. Not exactly microstutter (less abrupt) but similar. This is only the case while gaming or maybe it's just the only situation where I notice it.

I ended up switching to the other Display Input where it runs smooth while the LookingGlass client runs in the background.

I previously build some packages on the same distro for qubes which uses a similar technique (via RAM) which required me to enable the CONFIG_TRANSPARENT_HUGEPAGE_MADVISE kernel option on the client (which was linux but anyway). Otherwise it crashed. Maybe it's related. It's disabled on the host of my current system.

Hi, I've just ran through the build instructions for Fedora 27 workstation, and the following corrections might be useful for a fresh install:

Actual required package list for me was:

dnf groupinstall "Development Tools" "Development Libraries"
sudo dnf install git SDL2-devel SDL2_ttf-devel openssl-devel spice-protocol fontconfig-devel libX11-devel gnu-free-mono-fonts ivshmem-tools mesa-libGL-devel mesa-libGLU-devel

Without libGL and libGLU packages, make would error out with:

Package gl was not found in the pkg-config search path.
Perhaps you should add the directory containing `gl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gl', required by 'virtual:world', not found
Package 'glu', required by 'virtual:world', not found
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I../common -DDEBUG -ffast-math -fdata-sections -ffunction-sections  -DBUILD_VERSION='"a2-5-g2ae9b479f6"' -o .build/main.o main.c
In file included from lg-renderers.h:21:0,
                 from main.c:42:
lg-renderer.h:25:10: fatal error: SDL_ttf.h: No such file or directory
 #include <SDL_ttf.h>
          ^~~~~~~~~~~
compilation terminated.
make: *** [Makefile:28: .build/main.o] Error 1

Hello,

As far as I understand, it is normal that looking glass client looks unresponsive during UAC prompt. However, with the Keyboard (through spice) I could still somehow hit yes, or is that not possible?
If I hit the left arrow and then enter, then it seems to accept the UAC prompt (I double check with remote-viewer on the spice port).

However, looking glass host has crashed and I have to manually restart after every UAC prompt.

Is there any temporary workaround?

Thanks

Investigate a way to implement a keyboard capture mode that captures hotkeys destined for the window manager.

Ref Issue: #21

Host CPU: Intel Core i7-7700k @ 8x 4.5Ghz
Host GPU: GeForce GTX 1050
Guest GPU: GeForce GTX 1080
Host Kernel version: x86_64 Linux 4.15.13-1-vfio (ACS override patch as explained in the arch wiki)
Host QEMU version: 2.11.1

When I try to install or uninstall a program on my Windows 10 guest, the looking-glass freezes in a black screen for about 1 minute. After that everything workes fine again.
If I try the same thing while accessing the VM via virtmanager GUI, it works without problems.
The priority of the looking-glass-host is set to real-time.

Edit: This seems to happen everytime windows asks for administrator privileges.

I am using the latest version of the guest driver and the looking-glass-host.
The looking-glass-client comes from the AUR (https://aur.archlinux.org/packages/looking-glass/) and is started as follows: "looking-glass-client -s -w 1920 -b 1080 -k".

Required information

Host CPU: AMD FX(tm)-8320 Eight-Core Processor
Host GPU: [AMD/ATI] Curacao XT / Trinidad XT [Radeon R7 370 / R9 270X/370X]
Guest GPU: [AMD/ATI] Cape Verde PRO [Radeon HD 7750/8740 / R7 250E]
Host Kernel version: 4.16.12
Host QEMU version: QEMU emulator version 2.12.0
Using LookingGlass git master on client and host

I first noticed this when typing a password field and making a typo.

Steps to reproduce

1. Open notepad/wordpad
2. Type gibberish
3. Hold down the backspace key

Hello ! Thanks a lot for this amazing piece of software. It's really awesome.

I'm trying to make it work, and I get a lot of graphics bugs (Really fast blinking, half the screen black, ...). Is there anything to do ? I don't see anything in the logs

lou@5820k_Arch ~ % looking-glass-client -m -s
[I] main.c:560 | run | Looking Glass (a3-3-gcd54cb179b)
[I] main.c:636 | run | Initialized OpenGL
[I] ivshmem.c:153 | ivshmem_connect | RAM Size : 67108864
[I] main.c:762 | run | Waiting for host to signal it's ready...
[I] main.c:766 | run | Host ready, starting session
[I] main.c:235 | renderThread | Data Format: w=1920, h=1080, s=1920, p=7680, bpp=32
[I] opengl.c:159 | lgr_opengl_configure | Vendor : NVIDIA Corporation
[I] opengl.c:160 | lgr_opengl_configure | Renderer: GeForce GTX 770/PCIe/SSE2
[I] opengl.c:161 | lgr_opengl_configure | Version : 4.6.0 NVIDIA 387.34

If I try to start looking-glass-client with -v, I'm getting an error saying v is an invalid option.

I installed everything from AUR. My GPU is a 770, and my Windows GPU is a 1080

Also, do you know if 144hz is working ?

Thanks again

Host CPU: AMD Ryzen 7 1700X
Host GPU: GeForce GTX 560 (running proprietary nvidia driver 384.98)
Guest GPU: AORUS GeForce® GTX 1080 Xtreme Edition 8G
Distro: Ubuntu 16.04
Kernel: Linux demonbane 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
QEMU version: 2.6.2

I can get sub 40 FPS on Microsoft Basic Display Adapter which is nice but ultimately useless. Once I uninstall it via Device Manager in Windows it falls back to GTX 1080 after VM reboot. Then things go awry since I don't get more than 2 FPS when moving my mouse in the Looking Glass window.

What am I doing wrong

Required information

Host CPU: Intel i7-6700K
Host GPU: Intel HD Graphics 530
Guest GPU: GTX 980 Ti
Host Kernel version: 4.16.4-1-MANJARO
Host QEMU version: 2.11.1
Guest Windows version: Windows 10 RS3/1709

Changing ingame resolution dramatically (e.g. 720p->1440p), starting game with different ingame resolution than desktop, alt-tabbing out of game or into game can cause Host error and prompt to exit, refer to the corresponding log file for console output and see for its file name name for a short sumarry of what I did. Either way the issue can't be reproduced reliably.
For example:

• Changing ingame resolution causes DXGI's DuplicateOutput to produce error 80070005 and Clients video freezes but spice keeps working
• switching Monitor input to guest GPU to see its desktop
• closing looking-glass-host (or in my case creating dump file via task manager first)
• starting looking-glass-host
• alt-tabbing back to game
• switching monitor input to host
• noticing looking-glass-host errored again
• switching monitor input to guest GPU to see its desktop
• starting looking-glass-host
• alt-tabbing back to game
• switching monitor input to host
• this time no error

I couldn't isolate what causes looking-glass-host/capturer to error and fullscreening a game is a gamble for if LG will correspond badly or continue working. Changing just desktop resolution doesn't cause this issue. Desktop resolution and refresh rate is usually lower than ingame's setting then when switching to Game it often causes this issue but not exclusively.
Games I tested with are GTA5 and Rainbow Six Siege.

Required information

Host CPU: core-i7 4770
Host GPU: intel-hd graphics
Guest GPU: Nvidia G-Force 780-ti
Host Kernel version: Linux 4.15.15-1-ARCH #1 SMP PREEMPT Sat Mar 31 23:59:25 UTC 2018
Host QEMU version: qemu 2.11.1-2

Problem:
As soon as I press any Key on the Keyboard or the Mouse, the Looking-Glass-Client stops responding and is not updating the conted of the window anymore. It worked until I did the Arch Systemupgrade an hour ago. The Problem also occours when I disable the spice-client.

edit:
output from: looking-glass-client -f /dev/shm/looking-glass -c localhost -p 20001 -F

[I] main.c:680 | run | Looking Glass (a10-50-gfd8d4d3d38)
[I] main.c:681 | run | Locking Method: Atomic
[I] main.c:674 | try_renderer | Using Renderer: OpenGL
[I] main.c:762 | run | Using: OpenGL
[I] main.c:877 | run | Waiting for host to signal it's ready...
[I] spice.c:347 | spice_on_common_read | notify message: keyboard channel is insecure
[I] main.c:881 | run | Host ready, starting session
[I] main.c:172 | updatePositionInfo | client 1680x1050, guest 1680x1050, target 1680x1050, scaleX: 1.00, scaleY 1.00
[I] main.c:172 | updatePositionInfo | client 1674x1028, guest 1680x1050, target 1644x1028, scaleX: 1.02, scaleY 1.02
[W] main.c:175 | updatePositionInfo | Window size doesn't match guest resolution, cursor alignment may not be reliable
[I] main.c:172 | updatePositionInfo | client 1680x1050, guest 1680x1050, target 1680x1050, scaleX: 1.00, scaleY 1.00
[I] opengl.c:542 | configure | Vendor : Intel Open Source Technology Center
[I] opengl.c:543 | configure | Renderer: Mesa DRI Intel(R) Haswell Desktop
[I] opengl.c:544 | configure | Version : 3.0 Mesa 18.0.0
[I] opengl.c:575 | configure | Using decoder: NULL
[I] main.c:172 | updatePositionInfo | client 1680x1050, guest 1680x1050, target 1680x1050, scaleX: 1.00, scaleY 1.00

I don't think it sad decoder: NULL befor but I am not sure