The first fork of many
after typing make
Package gl was not found in the pkg-config search path.
Perhaps you should add the directory containing `gl.pc’
to the PKG_CONFIG_PATH environment variable
Package ‘gl’, required by ‘virtual:world’, not found
Package ‘glu’, required by ‘virtual:world’, not found
gcc -c -g -O3 -std=gnu99 -march=native -Wall -Werror -I./ -I…/common -DDEBUG -ffast-math -fdata-sections -ffunction-sections -DBUILD_VERSION=’“a2-0-g8c2709a3f4”’ -o .build/main.o main.c
In file included from lg-renderers.h:21:0,
lg-renderer.h:25:10: fatal error: SDL_ttf.h: No such file or directory
Seems I missed a dependency and need to correct SDL path. Make sure you have whatever flavor of libgl*-dev installed for your video card.
no errors now
cannot open shm file ivshmem: Permission denied
Please direct all support inquiries to this thread:
That said, try this:
sudo rm /tmp/ivshmem_socket
and run it again. (killing the ivshmem server leaves the socket file)
Small correction to fedora’s build documentation:
$ dnf install git mesa-libGL-devel mesa-libGLU-devel SDL2-devel SDL2_ttf-devel openssl-devel spice-protocol fontconfig-devel libX11-devel gnu-free-mono-fonts ivshmem-tools
Please submit it as an issue on the github repo
Again, its astonishing how the development of desktop virtualization has speed up in the last two years and this mostly in the open source world. We can hear the grass growing…
May I ask, when you first started to experiment with accessing the guest gpus framebuffer?
on archlinux it WORKS…
needed the extra packages
sd2 sdl2_ttf spice_protocol
also i did not realize for a bit that the ivshmem pid and socket file are accessed by the kvm user brainlag in action
fix was simple
sudo chmod o+rw "/tmp/ivshmem*"
but now it WOOORKS
thank you soooo much
PS: my system is still TR 1950x and dual vega … so i am assuming that is what causes my low performance and fps on the client (reaching from 2-30) with l
lookig forward to get that fixed as well … hopefully soon
About a week before I ran into the NPT problem.
So you build this from the ground up to todays stage in only two months, Impressive!
Yep sent Geoff my Vega. It’s something in Vegas pipeline only because amdgpu.dc =1 works fine w/fury but not Vega for whatever reason on kernel 4.15
Still working with MSI on TR pcie fixes. Lulz.
This brings up an interesting point. QEMU by default creates it’s own user to run stuff off of and set it’s own permissions. I think the fix should be as simple as telling people to modify their QEMU config to run off of their own user account and group instead.
And thank you very much! been keeping a keen eye out for the post man!
Man alive Vulkan needs a TON of initialization code, I am only I think 40-50% done and we are at 650 lines and counting.
Vulkan will be very handy as it is a lower level API than OpenGL. Combine that with the Nvidia capture API and those latencies would be insanely low.
Yeah, I’d say so… after a casual look over the API I think I can tell Vulcan to take the shared memory directly, removing one of the two CPU based memory copies we currently need to do with OpenGL.
It just takes a TON of code to just get it all setup…
We can also support Wayland, etc with this.
On GNOME 3 on Fedora, Wayland support will be really handy.
Though that will require an AMD card as the host. Nvidia and Wayland aren’t friends yet.
Yeah, see? and the community’s hostile stance towards “their way or the highway” ain’t helping things neither. We’re at a standstill.