Return to Level1Techs.com

A little teaser of what is to come :)


#520

The first fork of many


#521

hmm?
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,
from main.c:42:
lg-renderer.h:25:10: fatal error: SDL_ttf.h: No such file or directory
#include <SDL_ttf.h>


#522

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.

Fixed:


#523

no errors now :slight_smile:
moving forward


#524

cannot open shm file ivshmem: Permission denied
cannot bind

derp


#525

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)


#526

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


#527

Please submit it as an issue on the github repo


#528

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?


#529

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 looking-glass-client -ka

lookig forward to get that fixed as well … hopefully soon


#530

About a week before I ran into the NPT problem.

https://lists.linuxfoundation.org/pipermail/iommu/2017-October/024816.html


#531

So you build this from the ground up to todays stage in only two months, Impressive!


#532

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.


#533

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.


#534

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.


#535

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.


#536

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.


#537

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.


#538

#539

Yeah, see? and the community’s hostile stance towards “their way or the highway” ain’t helping things neither. We’re at a standstill.