Return to Level1Techs.com

Looking Glass - Guides, Help and Support

iommu
lookingglass

#21

Excellent, thanks for confirming that. Resizing seems is a problem with having spice disabled, I will fix that soon.

This is to be expected, the FPS is not the screen FPS, but the rate at which we are getting frames from the guest. If nothing has changed/updated then frames are ignored and not sent to the host.

Yup, confirmed, I will fix this.

Don’t do that… your IGP is plenty fast enough, just a few rough edges in Looking Glass.


#22

This is to be expected, the FPS is not the screen FPS, but the rate at which we are getting frames from the guest. If nothing has changed/updated then frames are ignored and not sent to the host.

Pardon my lack of knowledge on the tech, but would it be possible to force all frames to be sent regardless of changes? I wonder if that could ‘smooth’ things out.


#23

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.


#24

Cool, good to know.

Thanks!


#25

Fixed:


#26

Tagging this thread. And thanks for your work gnif.


#27

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 :).


#28

When i try to bind with

sudo -u qemu ivshmem-server -p /home/blabla/KVMFR/ivshmem.pid -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/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


#29

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.


#30

i modified the conf , same issue

running fedora 27


#31

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.


#32

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.


#33

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


#34

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.


#35
[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.


#36

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.


#37

Right, so modern renderer time.


#38

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


#39

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.


#40
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).