Return to

Looking Glass - Triage



AUR builds are not supported.

Switch to the EGL renderer -g egl, this is known and will be fixed soon. Please see the below where this problem has been covered.


that was it. I was using -o egl:vsync=0 but I wasn’t using -g egl and didn’t even think about checking the reported renderer in the console till just then


No worries. Also there is no need to specify vsync=0 for egl as it is the default for egl


I just pushed in a fix for this that also adds 10-bit RGBA support to the OpenGL renderer.


Hi gnif, Here’s my segmentation fault from the last client and host builds from master using EGL

(gdb) run -s -F -k -g egl
Starting program: /home/drew/bin/looking-glass-client -s -F -k -g egl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/".
[I]               main.c:752  | run                            | Looking Glass (a11-115-gd2b83027b4)
[I]               main.c:753  | run                            | Locking Method: Atomic
[I]               main.c:793  | run                            | Trying forced renderer
[I]               main.c:746  | try_renderer                   | Using Renderer: EGL
[New Thread 0x7fffedffe700 (LWP 18444)]
[I]               main.c:948  | run                            | Waiting for host to signal it's ready...
[I]                egl.c:387  | egl_render_startup             | Vendor  : NVIDIA Corporation
[I]                egl.c:388  | egl_render_startup             | Renderer: GeForce GTX 980 Ti/PCIe/SSE2
[I]                egl.c:389  | egl_render_startup             | Version : OpenGL ES 3.2 NVIDIA 415.18
[I]               main.c:957  | run                            | Host ready, starting session
[New Thread 0x7fffeca60700 (LWP 18445)]
[New Thread 0x7fffe6592700 (LWP 18446)]

Thread 4 "frameThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe6592700 (LWP 18446)]
0x00007ffff7776a2b in glGetUniformLocation ()
   from /usr/lib64/opengl/nvidia/lib/
(gdb) bt
#0  0x00007ffff7776a2b in glGetUniformLocation ()
   from /usr/lib64/opengl/nvidia/lib/
#1  0x00005555555654c5 in egl_on_frame_event (opaque=0x5555555ead00, 
    data=0x7fffef07f000 "[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]<\[email protected]>:\377=:6\377;84\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377\071\066\062\377"...)
    at /home/drew/src/LookingGlass/client/renderers/egl.c:310
#2  0x000055555555c606 in frameThread (unused=<optimized out>)
    at /home/drew/src/LookingGlass/client/main.c:424
#3  0x00007ffff7cb2dbc in ?? () from /usr/lib64/
#4  0x00007ffff7d23619 in ?? () from /usr/lib64/
#5  0x00007ffff58644f3 in start_thread () from /lib64/
#6  0x00007ffff69726df in clone () from /lib64/

I tried to keep it to a simple set of options in case one of them was triggering the issue.


I am kind of glad it is not happening only with me, I was going insane thinking it was something on my machine =D


Looking at the source I can not explain this failure nor can I replicate it here, would you be willing to let me remote debug the client on your system?

If so I will provide you with a public SSH key to authorize for access.

Edit: Would you also mind opening a github issue for this so that I can track it in Trello?.

Edit2: I think I found it, glGetUniformLocation was being called from a different thread to the OpenGL main context. This should be fixed now.


A series of changes were just committed to the repository that both clean up the code base and improve things. One commit in particular might have a large impact on the general smoothness of the video feed.

Previously the render thread was calculating a sleep delay to cap the frame rate. I have changed this to use the high resolution system timer to schedule an absolute wakeup time. This has two benefits:

  1. If we stutter and get behind, the render thread wont sleep and will catch up.
  2. The delay is more accurate allowing better frame sync.

I have also been able to gauge the performance impact of rendering the FPS display. I already knew that this was being done sub-optimal but now I have imperial data to prove that the FPS display causes micro stutter issues. I have added a warning to the output let people know about the issue.

This will not be fixed in A11, but it is queued up for the B2 release as the fix involves adding the code to generate and render fonts using a texture atlas.


Just woke up, I will check this when I can and report back. If it doesn’t work for some reason we can figure out a remote ssh. Thanks for the hard work.


I wont be around until late tonight AEST, have to go and visit my brother in law who just had his first child :smiley:


Hey! Congrats to him =D

I don’t think you need to worry about the issue anymore, your fix worked (=

Performance wise I can confirm what I saw a month ago: CPU utilization with EGL (even with 144fps @ 2560x1440) is minimal. GPU utilization is also better. Amazing work!


Yep. Working here on the latest client master as well.



Thanks, super glad to hear it, after the last few days it’s nice to get some good news!

Our trip to see our new nephew was a nightmare, had a postal worker on a push bike smash our car because “we ticked him off” by looking for a park, the idiot then rode off without providing any ID. Lost the entire day waiting for the police and dealing with them, thankfully they found the guy and charged him.

Then got home and shortly after we arrived home a lightning storm hit and a strike that was very close to us took out my managed switch, vdsl modem, UPS and gateway… sigh, one of those days.

Anyway, finally back and online, managed to cobble together some junk to get things running again in the meantime.


A12 was just released


Hey, just wanted to stop by and say thanks for the excellent work! I’ve been out of the game for a bit, but I’ve just downloaded and checked out A12 and it’s working pretty well from what I can see.



I’ve been using the adobe creative suite in a VM flawlessly since ancient version and it makes me so happy to be able to do that. Now we just need seamless window capture and we’ll be all set lololololol


That requires NVFBC, if I remember correctly.

But yeah, that’s on my list as well.


There is some example stuff in the amd media sdk for “remote desktop” which does window capture now too. So. That might be a thing… :smiley:


Oh, that’s good.


Hello ! I have a small problem with the Alpha 12 of the looking glass client. The Alpha 11 from the Arch repository works perfectly, but the A12 I built myself from source tells me this when I try to start it :

[I]               main.c:757  | run                            | Looking Glass ()
[I]               main.c:758  | run                            | Locking Method: Atomic
[I]               main.c:751  | try_renderer                   | Using Renderer: EGL
[I]               main.c:824  | run                            | Using: EGL
[E]               main.c:852  | run                            | Could not create an SDL window: Couldn't find matching GLX visual
  • I also tried to build the A11 from source just in case, it is working.
  • I tried the OpenGL renderer, the problem was the same.

Do you think you could help me ?

My config :
I7 9700K
Host GPU : HD 630
Passthrough GPU : 2080 TI
Motherboard : Z390 phantom gaming ITX/AC