Return to

Looking Glass - Guides, Help and Support



I am admin

I changed it:

srwxrwxrw- 1 admin users 0 13. čen 15.23 /run/user/1000/spice.sock

Still the same mistake.

  1. Please learn about the unix file security before you chmod things with 7s. 7 includes bit 1, which is the execute bit. Do you really plan to “run” your socket file as an application?

  2. This code is extremely new and alpha, seems like there may be a bug here, I will try to find some time to test and debug. In the meantime please use a local TCP socket.


I will try the latest version of git -


Please don’t, there has been no changes to this code since A11 was released.


I’m still thinking. Can I use the password at the Unix socket?


Again, this is an untested feature, please use a TCP socket.


OK, I wanted to try it because you wrote that:

UNIX socket support for lower latency input



Okay, pondering the OBS plugin for Looking Glass, I know that doing that outside of the main scope of the project is impractical… so what about this?

Allow the RGB buffers to be dumped straight to a stubbed out link to /dev/video0 or /dev/video1 for V4L2, with the Looking Glass client itself doing the conversion in buffer/packet structure to V4L2, and then OBS is able to use the V4L2 framework to capture the buffers. From a dev standpoint, would make perfect sense for screenshare recording to send those buffers to any V4L2 program, not just OBS.

Heck, Kdenlive could even capture Looking Glass output in this fashion.


The concept is sound, but at this time the time I have to work on this project is being put into tuning and optimization. Once we get to a 1.0 release I will start evaluating additional features to add, including V4L/OBS, etc. To be honest though it would make more sense to make OBS KVMFR aware directly to avoid additional memory copies.


Yeah, but OBS KVMFR is the one that requires the most dev resources. A V4L2 muxer in the client would integrate well with the client in it’s current state, since V4L2 takes in raw buffers I think.


Perhaps so, but even still this is a discussion for another day :slight_smile:


Would it be possible to setup CI/CD testing?


Well, think of it this way, now that VM to VM and Linux VM to Linux Host communications are possible, people could finally screen record a VM without using OBS’ broken “Screen Capture (XSHM)” and the inability for “Window Capture” to capture Terminal windows, or do proper screenshare using a V4L2 and WebRTC grabbing a V4L2 device rather than using something botchy in Chrome or Firefox for screen share for presentation purposes.

XSHM in OBS is notorious for “tearing” captures. It was present in the cats per second video.


IVSHMEM passthrough to a Linux VM is possible now (where LG client runs)?




getting the following when attempting to start the LG client on gentoo:

Any ideas?

EDIT: Turns out I did not build QEMU with opengl support, building QEMU with opengl support resolved the issue. Now if only I can figure out to how to get virt-manager to pass through a 360 controller to W10 so that it doesn’t complain and disable the controller.



Virt-manager: “add hardware->USB Host device->select XBOX controller device” didn’t work for you?