Return to

Looking Glass - Triage


It actually makes things worse, it’s much cheaper CPU and GPU wise to only take the difference frames, the capture API actually directly supports this and tells us if things have changed or not.

For example, two frames are identical, the first one is just shown on the guest for that entire period instead of re-drawing when nothing has changed. During this redraw we would be busy wasting time when we could be processing other things.

The exception to this is the hardware cursor, we flush that to screen immediately.

1 Like


Cool, good to know.



split this topic #24

54 posts were merged into an existing topic: Looking Glass - Changelog



Tagging this thread. And thanks for your work gnif.

1 Like


This should be fixed now, please update to the latest version. Please be sure to update the windows host application to alpha3 also. Binary available on the website & github.

Note: I do not have a monitor capable of this resolution so I can’t verify it’s fixed, that’s up to you :).



When i try to bind with

sudo -u qemu ivshmem-server -p /home/blabla/KVMFR/ -S /home/blabla/KVMFR/ivshmem_socket -l 16M -n 8

It says cannot bind (before opening VM)

The VM also refuses to start.

Error starting domain: internal error: process exited while connecting to monitor: 2017-12-14T10:45:44.853770Z qemu-system-x86_64: -chardev socket,path=/home/blabla/KVMFR/ivshmem_socket,id=ivshmem: Failed to connect socket /home/blabla/KVMFR/ivshmem_socket: Connection refused

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/”, line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/”, line 125, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/”, line 82, in newfn
ret = fn(self, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/”, line 1505, in startup
File “/usr/lib64/python2.7/site-packages/”, line 1062, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirtError: internal error: process exited while connecting to monitor: 2017-12-14T10:45:44.853770Z qemu-system-x86_64: -chardev socket,path=/home/blabla/KVMFR/ivshmem_socket,id=ivshmem: Failed to connect socket /home/blabla/KVMFR/ivshmem_socket: Connection refused



Is qemu running as ‘qemu’ or ‘kvm’, or ‘libvirt’. You might need to check as each distro is different. I found the easiest way to make all this function without security risk is to just run the VM as your local user.

Edit /etc/libvirt/qemu.conf and set user = "blabla", and group = "blabla", restart libvirt and see how you go.



i modified the conf , same issue

running fedora 27



Sorry I am not going to be able to diagnose this one for you, it’s a permissions issue, you will need to look into how libvirt is launching qemu and correct for it. Later we will look at writing some guides but at the moment my focus is 100% on the Looking Glass code base.



Use /tmp for sockets. The qemu user won’t have access to your home directory. I am on Fedora 27 in enforcing and it works fine.



No dice on Intel HD 3000 as host on a 3770.



Log? I bet OpenGL failed to init.

Since this was all based on proof of concept code I used legacy OpenGL, it needs another renderer (not an update to the current one, completely separate one so we have legacy fallback) written for modern GL with VBOs. Some cards do not support legacy anymore.

Next step for me is adding Vulkan first, once that is done I will revisit OpenGL unless someone else does before me.


[I]               main.c:560  | run                            | Looking Glass (a2-5-g2ae9b479f6-dirty)
[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
[I]               main.c:235  | renderThread                   | Data Format: w=1920, h=1080, s=1088, p=4352, bpp=32
[I]             opengl.c:159  | lgr_opengl_configure           | Vendor  : Intel Open Source Technology Center
[I]             opengl.c:160  | lgr_opengl_configure           | Renderer: Mesa DRI Intel(R) Ivybridge Desktop 
[I]             opengl.c:161  | lgr_opengl_configure           | Version : 3.0 Mesa 17.2.4
[E]             opengl.c:97   | lgr_opengl_check_error         | glTexImage2D = 1282 (invalid operation)
[E]               main.c:240  | renderThread                   | Failed to reconfigure OpenGL

Looking for GL_ARB_buffer_storage is actually supported on here. I don’t know much about graphics programming at all, so short of stepping through gdb it’ll take me some time to figure out what’s going on.



No need to step through, regarding Legacy OpenGL

Intel provides an implementation for Windows up to OpenGL 3.1 with Sandy Bridge CPUs and OpenGL 4.0 with Ivy Bridge CPUs. However, Intel’s Linux open-source driver developers have recently stated that they will not provide backward-compatibility on Linux.

GL_ARB_buffer_storage is 4.3, too new to be used with the Legacy API on your GPU.

Once someone (or I) write a modern OpenGL renderer into the client this will be resolved.



Right, so modern renderer time.



I managed to have the vm run

I did the following

Edit /etc/libvirt/qemu.conf and set

user = "qemu"
group = "qemu"
dynamic_ownership = 1

Now I get this

[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

Even though it did bind before running the vm



make sure you specify the socket path to looking-glass-client if you changed it. Also ensure the client has permission to use the socket, check the file’s permissions.


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

Removing the -Werror flag will make it work. Not sure this will have any impact.

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



Hah. We were both wrong, it works fine. Turns out it was because the host monitor was in portrait mode 1080x1920 (on my second screen which is portrait. Flipping it up the other way works fine. I am guessing the windows host communicates dimensions wrong/no orientation at all.

1 Like


Correct, it wasn’t deemed important at this point in time.