Can it stream multiple monitors?If yes then with different resolutions too?(not for gaming)
Welcome to the community @Zsolt_Madlen :).
At this time it’s single monitor only I am sorry, the logistics of multiple monitors is beyond scope (for now)
I’ve been running LookingGlass A10 for a while and it was awesome. Sadly a couple of days ago it stopped working. Initially I thought it might be due to KDE Plasma which I’ve installed recently. But when I’ve switched back to Gnome the problem persisted.
WHen I launch it I get:
[E] opengl.c:521 | configure | Failed to create the OpenGL context
*** Error in `/home/przemek/Dokumenty/Github/LookingGlass-a10/client/bin/looking-glass-client’: free(): invalid pointer: 0x00000000018760e0 ***
Tried using A12. Sadly it is not working either. This time I get:
[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
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0x0
Serial number of failed request: 240
Current serial number in output stream: 247
Naruszenie ochrony pamięci (zrzut pamięci)
The last sentence means “memory protection error”, just in case 
.
Any ideas what can I try doing to get it back and running? It has become quite important part of my work - allows me to prepare tutorials for my students (Windows CAD apps related) even though I have Windows only in VM on my home machine.
I’m on OpenSUSE Leap 15, Nvidia 418.56 (that’s another thing that might have been updated recently), X11 1.19.6.
edit: got A12 working. It seems it is a simple thing - permission setup to the ivshmem file. Set it up to 666 
for a test and it worked.
Quite surprised that it trips A12 as with the same permissions A10 worked. But also glad I’ve got it working as it seems with this version using the mouse from the host works flawlessly (no need to scrlk ).
edit2: damn it, it is not so easy. Restarted the VM and tried using LG again and it failed… again … Tried launching LG as root (I know - not the best idea in the world, but wanted to rule out permission issues). Didn’t help:
[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
*** Error in `./looking-glass-client': corrupted double-linked list: 0x00000000010c5fb0 ***
Przerwane (zrzut pamięci)
The same when I’ve tried OpenGL backend. Tried one more time… it started…
Any suggestions howto fix it greatly appreciated.
At this point I’m trying to start LG a couple of times hoping that at one time it will launch .
The issue is that Wayland require GBM vs nVidias EGLStreams. In fact pretty much all of the Linux ecosystem* has decided to leave EGLStreams as a secondary, also-supported thing.
Some support may still exist for it, but do not expect the Linux ecosystem to bend over backwards on this issue.
*You will always be able to find that project that just contradicts all I said of course, with almost no mainstream support…
Please see DEBUGGING.md
Or update to the lastest build in git as it has some inbuilt debugging now for issues like this.
sure, will do. Where should I look for the log?
The info I got so far is:
[I] main.c:751 | try_renderer | Using Renderer: EGL
[I] main.c:824 | run | Using: EGL
*** Error in `/home/przemek/Dokumenty/Github/LookingGlass-a12/client/build/looking-glass-client': corrupted double-linked list: 0x000000000089cf60 ***
Program received signal SIGABRT, Aborted.
0x00007ffff5777120 in raise () from /lib64/libc.so.6
(gdb) thread apply all bt
Thread 1 (Thread 0x7ffff7fb2b80 (LWP 4081)):
#0 0x00007ffff5777120 in raise () from /lib64/libc.so.6
Backtrace stopped: Cannot access memory at address 0x7fffffff7a58
edit: and more on the 3rd run (I’m still “hunting” some of the missing debuginfo packages):
[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
*** Error in `/home/przemek/Dokumenty/Github/LookingGlass-a12/client/build/looking-glass-client': corrupted double-linked list: 0x000000000085d000 ***
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 }
(gdb) thread apply all bt
Thread 1 (Thread 0x7ffff7fb2b80 (LWP 6462)):
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff5778701 in __GI_abort () at abort.c:79
#2 0x00007ffff57ba467 in __libc_message (action=action@entry=(do_abort | do_backtrace), fmt=fmt@entry=0x7ffff58c3370 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff57c0c83 in malloc_printerr (action=<optimized out>, str=0x7ffff58bfc5e "corrupted double-linked list", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5428
#4 0x00007ffff57c45f1 in _int_malloc (av=0x7ffff5af5c20 <main_arena>, bytes=24) at malloc.c:4030
#5 0x00007ffff57c5ae7 in __GI___libc_malloc (bytes=24) at malloc.c:3081
#6 0x00007ffff699b4b2 in PutEntry (db=db@entry=0xa59250, bindings=0x7fffffff8194, bindings@entry=0x7fffffff8190, quarks=0x7fffffff7ff4, quarks@entry=0x7fffffff7ff0, type=385,
value=value@entry=0x7fffffff7fe0) at Xrm.c:958
#7 0x00007ffff699c201 in PutEntry (value=0x7fffffff7fe0, type=<optimized out>, quarks=0x7fffffff7ff0, bindings=0x7fffffff8190, db=0xa59250) at Xrm.c:854
#8 GetDatabase (db=db@entry=0xa59250,
str=0x648d26 "\n*Canvas.background:\t#1c1c1c\n*Canvas.foreground:\t#ebebeb\n*Canvas.highlightBackground:\t#1c1c1c\n*Canvas.highlightColor:\t#ebebeb\n*Canvas.selectbackground:\t#53728e\n*Canvas.selectforeground:\t#ffffff\n*Check"...,
str@entry=0x648bf0 "*Box.background:\t#323232\n*Box.foreground:\t#ebebeb\n*Button.activeBackground:\t#323232\n*Button.activeForeground:\t#ebebeb\n*Button.background:\t#323232\n*Button.foreground:\t#ebebeb\n*Button.highlightBackgroun"..., filename=filename@entry=0x0, doall=doall@entry=1, depth=depth@entry=0) at Xrm.c:1513
#9 0x00007ffff699ce6b in XrmGetStringDatabase (
data=0x648bf0 "*Box.background:\t#323232\n*Box.foreground:\t#ebebeb\n*Button.activeBackground:\t#323232\n*Button.activeForeground:\t#ebebeb\n*Button.background:\t#323232\n*Button.foreground:\t#ebebeb\n*Button.highlightBackgroun"...) at Xrm.c:1561
#10 0x00007ffff6979154 in InitDefaults (dpy=dpy@entry=0x638500) at GetDflt.c:148
#11 0x00007ffff69793f8 in XGetDefault (dpy=dpy@entry=0x638500, prog=prog@entry=0x7ffff34b079d "Xcursor", name=name@entry=0x7ffff34b082f "core") at GetDflt.c:220
#12 0x00007ffff34ad8d3 in _XcursorGetDisplayInfo (dpy=0x638500) at display.c:151
#13 0x00007ffff34ad939 in XcursorSupportsARGB (dpy=dpy@entry=0x638500) at display.c:288
#14 0x00007ffff34ac134 in XcursorImageLoadCursor (dpy=<optimized out>, image=<optimized out>) at cursor.c:554
#15 0x00007ffff7967ef5 in X11_CreateXCursorCursor (hot_y=4, hot_x=4, surface=0x69c4f0) at /usr/src/debug/SDL2-2.0.8-lp150.2.3.1.x86_64/src/video/x11/SDL_x11mouse.c:110
#16 X11_CreateCursor (surface=0x69c4f0, hot_x=4, hot_y=4) at /usr/src/debug/SDL2-2.0.8-lp150.2.3.1.x86_64/src/video/x11/SDL_x11mouse.c:214
#17 0x00007ffff78d1d48 in SDL_CreateColorCursor_REAL (surface=<optimized out>, surface@entry=0x69c4f0, hot_x=hot_x@entry=4, hot_y=hot_y@entry=4)
at /usr/src/debug/SDL2-2.0.8-lp150.2.3.1.x86_64/src/events/SDL_mouse.c:872
#18 0x00007ffff78d1ee3 in SDL_CreateCursor_REAL (data=0x7fffffffd788 " \\\257\365\377\177", mask=0x7fffffffd788 " \\\257\365\377\177", w=8, h=8, hot_x=4, hot_y=4)
at /usr/src/debug/SDL2-2.0.8-lp150.2.3.1.x86_64/src/events/SDL_mouse.c:833
#19 0x000000000040931f in run () at /home/przemek/Dokumenty/Github/LookingGlass-a12/client/main.c:905
#20 0x0000000000406f73 in main (argc=<optimized out>, argv=0x7fffffffda38) at /home/przemek/Dokumenty/Github/LookingGlass-a12/client/main.c:1623Next time you need to post pre-formatted text please use the “pre-formatted” text feature. I have fixed your post to make the information readable.
Where should I look for the log?
What you posted is the log.
(I’m still “hunting” some of the missing debuginfo packages):
What do you mean? What you provided here points out exactly where the failure is ocurring, the call to SDL_CreateCursor in main.c on line 905.
Since there is no issue with the code at this point and it’s during early initialisation I would suggest you perhaps have a hardware issue, or an issue with the SDL library itself.
- Please post the entire debug session, including how you invoked gdb, what arguments you’re running with, etc.
- What OS are you running?
- What hardware are you running on?
- Is your system overclocked?
- Can you please try the latest master version in git?
LOL, simply thought there’s some sort of log file written somewhere. Thx for the patience Gnif 
.
Bear with me, I’m not a programmer (a mere desktop user) so lots of this stuff is new to me - but I’m doing my best .
As for debug packages - initially when I followed the instruction there was not much info given, but I got a warning that there are some debuginfo packages missing. Narrowed it down to 3 still missing if I recall correctly (gl/egl ones - got debuginfo for mesa ones, but I guess there are none for nvidia?).
Here’s output of inxi -b command on my home machine:
System: Kernel: 4.12.14-lp150.12.58-default x86_64 bits: 64 Desktop: KDE Plasma 5.12.8
Distro: openSUSE Leap 15.0
Machine: Device: desktop Mobo: ASRock model: EP2C602 serial: 149024860000174
UEFI: American Megatrends v: P1.80 date: 12/09/2013
CPU(s): 2 Octa core Intel Xeon E5-2670 0s (-HT-MCP-SMP-) speed/max: 2600/3300 MHz
Graphics: Card-1: NVIDIA GM204 [GeForce GTX 980]
Card-2: Advanced Micro Devices [AMD/ATI] RV730 GL [FirePro V7750]
Display Server: x11 (X.Org 1.19.6 ) driver: nvidia Resolution: [email protected], [email protected]
OpenGL: renderer: GeForce GTX 980/PCIe/SSE2 version: 4.5.0 NVIDIA 418.56
Network: Card: Intel 82574L Gigabit Network Connection driver: e1000e
Drives: HDD Total Size: 2360.5GB (73.3% used)
I get the same problem on other workstation. It has Leap 15 installed as well, but other than that it is pretty different (It also has old dual Xeons, but other ones, Nvidia 1060 and 1030, with 1030 used for VM). I’ll check whether SDL libraries are the same on both machines.
Initially I’ve tried the master branch but I couldn’t compile it - and as I’m not a programmer I’ve lacked knowledge to solve the issue. Will re-try in the weekend and will post what I got.
Currently once in 4-5 attempts LookingGlass starts.
You’re welcome.
Bear with me, I’m not a programmer (a mere desktop user) so lots of this stuff is new to me - but I’m doing my best
I appreciate the fact that you’re putting the effort in to providing the debug information.
but I got a warning that there are some debuginfo packages missing
This doesn’t affect things, the back trace provided contains enough information to pinpoint where the failure is happening.
I just had another look through all the initialisation code leading up to this point and I can not see anything in LG that would/could cause such a fault (memory corruption). Even the EGL initialisation at this point has practically done nothing.
Since the fault is random, the process is not even multi threaded yet at this point, and all memory allocations are checked for failure I believe the issue lies outside of LG with your system, perhaps a faulty build of SDL2 or a hardware fault.
You could try running LG under valgrind which should be able to identify what is corrupting the memory.
valgrind ./looking-glass-host
Please post the entire output, if it’s large please use pastebin. Also please note that valgrind will slow down LG enormously as it’s tracing every memory allocation, read and write to try to identify memory corruption faults.
That was my initial fear. But as I get this on 2 different workstations doesn’t it seem less likely? Will check SDL libraries - if they’re the same on both PCs I’ll look for different build and will re-check.
I’ll also look whether logs look similar (pointing to SDL).
Will also check it with Valgrind as suggested - will get back when I’ll collect all this data .
1 Like
Indeed it does, I am more inclined to think a software fault somewhere.
Excellent, this is ideally the best next step in debugging this issue.
I’ve just installed Fedora 30, and I seem to be having issues with compiling the client, I’ve made sure all the necessary packages are installed, cmake works, however, after running ‘make’ returns the following:
[static-dragon@Enterprise-C build]$ make
[ 4%] Building C object CMakeFiles/looking-glass-client.dir/spice/spice.c.o
/tmp/mozilla_static-dragon0/LookingGlass-a12/client/spice/spice.c:39:10: fatal error: spice/error_codes.h: No such file or directory
39 | #include <spice/error_codes.h>
| ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/looking-glass-client.dir/build.make:141: CMakeFiles/looking-glass-client.dir/spice/spice.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/looking-glass-client.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
I should note that I am trying to compile a12, not the git version, as the git version returns an error regarding wayland-egl missing when running cmake
ok, so tomorrow I’ll be checking LG with Valgrind. But so far I’ve been able to confirm very similar error output on the PC in the workshop (as suspected).
Also tried building master branch. During “make” I got:
Scanning dependencies of target looking-glass-client
[ 88%] Building C object CMakeFiles/looking-glass-client.dir/src/main.c.o
[ 90%] Building C object CMakeFiles/looking-glass-client.dir/src/app.c.o
[ 92%] Building C object CMakeFiles/looking-glass-client.dir/src/config.c.o
[ 94%] Linking C executable looking-glass-client
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/7/../../../../lib64/libbfd.a(plugin.o): undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /lib64/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/looking-glass-client.dir/build.make:173: looking-glass-client] Błąd 1
make[1]: *** [CMakeFiles/Makefile2:82: CMakeFiles/looking-glass-client.dir/all] Błąd 2
make: *** [Makefile:130: all] Błąd 2The spice package maintainers removed the header, you will need to update to the latest master version of Looking Glass, or wait for B1.
Ensure you have the binutils dev package installed
checked - have it. Didn’t previous versions of LG had that dependency? Up to current master branch those compiled correctly.
No, it’s a new dependency.
I have both binutils and binutils-devel installed, turns out I was missing wayland-devel, both cmake and make worked successfully this time, thank you.
1 Like
here’s what Valgrind gave me (a12 release):
[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
==6492== Invalid write of size 8
==6492== at 0x4C32673: memcpy@GLIBC_2.2.5 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x510BEE5: X11_CreateXCursorCursor (SDL_x11mouse.c:108)
==6492== by 0x510BEE5: X11_CreateCursor (SDL_x11mouse.c:214)
==6492== by 0x5075D47: SDL_CreateColorCursor_REAL (SDL_mouse.c:872)
==6492== by 0x5075EE2: SDL_CreateCursor_REAL (SDL_mouse.c:833)
==6492== by 0x40931E: run (main.c:905)
==6492== by 0x406F72: main (main.c:1623)
==6492== Address 0xee94b78 is 0 bytes after a block of size 296 alloc'd
==6492== at 0x4C2E01F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x996202D: XcursorImageCreate (file.c:37)
==6492== by 0x510BEA6: X11_CreateXCursorCursor (SDL_x11mouse.c:97)
==6492== by 0x510BEA6: X11_CreateCursor (SDL_x11mouse.c:214)
==6492== by 0x5075D47: SDL_CreateColorCursor_REAL (SDL_mouse.c:872)
==6492== by 0x5075EE2: SDL_CreateCursor_REAL (SDL_mouse.c:833)
==6492== by 0x40931E: run (main.c:905)
==6492== by 0x406F72: main (main.c:1623)
==6492==
valgrind: m_mallocfree.c:280 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.
host stacktrace:
==6492== at 0x580442FA: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==6492== by 0x58044414: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==6492== by 0x58044599: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==6492== by 0x580533CC: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==6492== by 0x5800BAB4: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==6492== by 0x5800BC96: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==6492== by 0x580A00C5: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==6492== by 0x580AF730: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 6492)
==6492== at 0x4C2E01F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6492== by 0x99613C1: _XcursorGetDisplayInfo (display.c:124)
==6492== by 0x9961938: XcursorSupportsARGB (display.c:288)
==6492== by 0x9960133: XcursorImageLoadCursor (cursor.c:554)
==6492== by 0x510BEF4: X11_CreateXCursorCursor (SDL_x11mouse.c:110)
==6492== by 0x510BEF4: X11_CreateCursor (SDL_x11mouse.c:214)
==6492== by 0x5075D47: SDL_CreateColorCursor_REAL (SDL_mouse.c:872)
==6492== by 0x5075EE2: SDL_CreateCursor_REAL (SDL_mouse.c:833)
==6492== by 0x40931E: run (main.c:905)
==6492== by 0x406F72: main (main.c:1623)
When it comes to master branch I still haven’t figured out why it is failing at the “make” stage (as posted above - binutils-devel is installed). But I’m searching … and asking around …
tried switching SDL2 packages in my system. Found 2.0.9 in the experimental repos (in the regular ones there’s 2.0.8). So far seem to do the trick - A12 now starts normally.
So only figuring out compiling of the master branch left.
Thx Gnif!
edit: btw - what is the full dependencies list for current master branch? I’d like to go one by one and make sure I have all that is needed. I hope it is a simple case of missing a package that prevents master branch from compiling on my end.