I see, then the permissions of the file on the host should be fine. The VM that runs the server should be fine also, if you have setup the server properly. I however do not know what settings you need to access the shm file from another Linux VM.
What happends when you run ./looking-glass on the client VM?
./looking-glass-client
[I] 68065626 main.c:1064 | main | Looking Glass (B4)
[I] 68065659 main.c:1065 | main | Locking Method: Atomic
Invalid value provided to the option: app:shmFile
Error: Invalid path to the ivshmem file specified
Valid values are:
i think it looks for /dev/shm/looking-glass, which does not exist on the Linux VM. it is /dev/uio0.
Sorry then I can’t help you further. I have no prior experience with a setup like this. But from what I read the first time you tried to run this command including the -f flag, it had problems with you shared memory file. I think the compilation went successful.
so then i guess the breaking/removal of this functionality is just a property of the newer LG? problem for another thread then.
I am sure it still works, but something is setup wrong on your end. I am not a developer and don’t know what might have changed. I use only the simple setup, with client on host and server on guest. I have no experience with VM to VM sharing.
turns out it was DKMS’ fault all along!
somehow updating my kernel DKMS’ diddnt automatically re-inject the kvmfr module.
/dev/uio0 turn into /dev/kvmfr0 on my Linux VM.
now the problem is that Looking-glass crashes ta launch with:
[I] 175980458 main.c:1064 | main | Looking Glass (B4)
[I] 175980496 main.c:1065 | main | Locking Method: Atomic
[W] 175981191 option.c:301 | option_parse | Ignored invalid argument: yes
[I] 175981254 ivshmem.c:127 | ivshmemOpenDev | KVMFR Device : /dev/kvmfr0
[I] 176073203 main.c:671 | tryRenderer | Using Renderer: OpenGL
[I] 176158394 x11.c:303 | x11Init | X11 XInput 2.0 in use
[I] 176163238 opengl.c:540 | opengl_render_startup | Vendor : AMD
[I] 176163263 opengl.c:541 | opengl_render_startup | Renderer: AMD Radeon RX 5700 (NAVI10, DRM 3.40.0, 5.10.46-mathew2214-fsync, LLVM 12.0.0)
[I] 176163266 opengl.c:542 | opengl_render_startup | Version : 4.6 (Compatibility Profile) Mesa 21.1.0
[I] 176163294 opengl.c:554 | opengl_render_startup | Using GL_AMD_pinned_memory
./looking-glass-client: symbol lookup error: ./looking-glass-client: undefined symbol: glXSwapIntervalEXT
seems to be the same issue as Looking glass run error - #8 by FooLKiller
This is caused by the drivers from AMD. If you install the firmware for the open source drivers on a recent kernel, 5.10+, then remove the amd provided drivers, update initramfs and you’re good to go.
Note that you should rename your shared memory device to /dev/shm/looking-glass for ease of upgrades in the future. You do not want shared memory in dev. That directory is secured for a reason.
Also, if cmake fails, you are missing things you need…
i have kernel 5.10+. i am not using amdgpupro. i use amdgpu and mesa.
my firmware is provided by debian’s firmware-amd-graphics package.
can you link the “open source firmware”? a quick google shows nothing in Debian’s default repo. i may need to get creative here.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/about/
Source: Ubuntu 20.10 + RX 6800 XT - How To Steam / Vulkan Up And Runing Guide [WIP]
Note, don’t follow that guide other than just for the firmware installation.
thank you for the link. but yeah…no.
changing my firmware files to those completely destroys the entire system’s graphical performance.
surely there must be a way to use looking glass client without also making the system unusable for 3D acceleration.
debian 11
linux 5.10
mesa 21.1
That’s funny. I use the same files on my setup and it works fine. It also works for many other people as that is a guide from Level1.
You need to remove the AMD provided drivers FIRST before you install that firmware and update initramfs with the new driver firmware. Then reboot and see. If you don’t have graphical performance, check to see if it gives the firmware error on initramfs -u. If it does, you popped them into the wrong spot.
The open source drivers are faster than the AMD provided ones on this system.
Maybe hit the Looking Glass guy up and see if he can point you in the right direction. Likely he’s got about 500 bug reports for that issue.
after upgrading to linux 5.13, same results. the binaries in that link just kill performance. no errors when making my initramfs, no errors in dmesg when using those files. it boots without error, but the performance is unbearable.
update: using some mesa debugging enviroment variables and the firmware that still allows for a usable desktop i got
libEGL debug: EGL user error 0x3008 (EGL_BAD_DISPLAY) in eglQueryString
Debian 11
Linux 5.13
Navi10
Mesa 21.2.1
Incorrect, he is using the kvmfr kernel module which provides the virtual memory via /dev/kvmfr0 (formally /dev/uio0) for his VM to VM configuration. This is a device node and can not be renamed/moved.
Just a note, I’m setting up Looking Glass on a new machine. Building the bleeding-edge client on a fresh Ubuntu 21.10 install, a few build dependencies were missing. Took a few notes, here they are:
sudo apt install git before git command (duh)
cmake:
No CMAKE_CXX_COMPILER could be found.
need sudo apt-get install build-essential
No package ‘xkbcommon’ found
sudo apt-get install -y libxkbcommon-dev
No package ‘xcursor’ found
sudo apt install libxcursor-dev
No package ‘xpresent’ found
sudo apt install libxpresent-dev
make
LookingGlass/client/include/egl_dynprocs.h:28:10: fatal error: GLES3/gl3.h: No such file or directory
sudo apt install libgles-dev
no replies necessary (flames or thanks). just thought the developers might want to update the build instructions page and thought it might help.
I compile Looking Glass host and guest automatically in here to try to simplify things for the user.
Eventually I think it should be possible to modify the Windows installer ISO file to include Looking Glass and the IVMSHMEM automatically using something like this:
I will try to take a stab at that sometime before long. Of course the user will still need to bring their own Windows ISO and license key.
Does anyone know where to find module ‘samplerate’? It’s required to build from master and I can’t seem to track it down.
If I were a gambling man I’d say that’s a header file from libsamplerate you’re missing. Might be named slightly different depending on your distro.