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 looking-glass-client -ka
lookig forward to get that fixed as well … hopefully soon
About a week before I ran into the NPT problem.
https://lists.linuxfoundation.org/pipermail/iommu/2017-October/024816.html
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.
Well well well… This just got announced for people using Linux as the guest OS… Exciting times indeed.
https://www.phoronix.com/scan.php?page=news_item&px=VirtIO-DRM-Window-Server
That’s cool… I will be able to play my Linux games without dualbooting finally… oh wait. 
Clone a Linux Guest and have LAN multiplayer on one screen.
The trick will be to run Linux in a Nested Hyper-V VM on Windows running on KVM… and then in the nested Linux run Dosbox…
Inception!
Believe it or not, with Rocket League, a game that is truly multiplatform, one Steam account per OS works in this fashion.
If you have Wine, once they get D3D11 to a usable state in Vulkan, Windows VM and Wine running Overwatch at the same time sounds cool. (it has to be Vulkan cause the D3D11 to OpenGL that Wine staging currently has is extremely taxing on the CPU. You basically need Threadripper for decent performance, assuming the OpenGL renderer can multithread.)
You’re funny. I like you.
But on a serious note, this method would probably be easier to do than my other idea of creating a nested Wayland session for split-screen:
CRAP! Looking Glass is on the top trending list of projects on GitHub!
Its number one for projects written in C
I wouldn’t expect any less. This project is pretty amazing!