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.
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 :).
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/asyncjob.py”, line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 125, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/libvirtobject.py”, line 82, in newfn
ret = fn(self, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/domain.py”, line 1505, in startup
self._backend.create()
File “/usr/lib64/python2.7/site-packages/libvirt.py”, 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.
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.
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.
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.
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.
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.