homebrew-qemu-virgl VS barrier

If you want a DE like GNOME or KDE then use this qemu package, graphics run like butter IMO on my M1 MacBook Air (though only on Linux guests, not Windows) https://github.com/knazarov/homebrew-qemu-virgl

I didn't use this, but a similar/related project that is for MacOS, https://github.com/knazarov/homebrew-qemu-virgl

Vagrant is an orthogonal tool to this, it is a VM orchestrator not an actual VM. What does this do: well, qemu doesn't have virgl support merged yet, so you need to go to some lengths to compile it for yourself.

All of the other stuff (spice, virtio) is for "it should be a nice user experience" above and beyond simply fast. In other words, you should be able to copy and paste between the host OS and the guest. You should be able to slide your mouse across the border of the VM window and do some clicking around then simply slide it back out and use your mouse with native host-OS windows again.

These things are all not granted when you use qemu out of the box. I have this intense 25-lines "qemu" script for invoking qemu-system properly. It was enlightening but I'm not sure how much I was enriched by the process of actually figuring all this out.

Quickemu is for making this easier (and on Linux.)

How about the build with VIRGL support here?

I recently discovered QEMU, switched from VirtualBox on my Mac (Intel, Big Sur), and have been loving the improved performance. Running Linux Mint is amazing, especially after knazarov's homebrew package of the 3D-accelerated QEMU-Virgl project.

For software KVM you can use https://github.com/debauchee/barrier

I use it between a Windows PC & a Macbookpro (Linux version available but I don't have Linux)

libei looks useful. But IDK why libei is necessary to run Barrier with Wayland?

For client systems, couldn't there just be a virtual /dev/inputXYZ that Barrier forwards events through

And for host systems, it looks like xev only logs input events when the window is focused.

Is xeyes still broken on Wayland, and how to fix it so that it would work with Barrier?

With Barrier, when the mouse cursor reaches a screen boundary, the keyboard and mouse input are then passed to a different X session on another box until the cursor again crosses a screen boundary rule.

Barrier is a fork of Synergy's open core: https://github.com/debauchee/barrier

libei:

I have a similar gaming/WFH setup (2 monitors at 1440p 144hz) and I’ve been using Barrier instead of a physical kvm, and it works really well. Not sure if you’re open to a software kvm but if you are, I’m happy to answer any questions about it if you have any.

Have you tried Barrier? I casually used it to swap between my main rig and my MBP. Took a minute to get it setup but once I sorted it all out it worked pretty well. It has some settings and tweaks built in to address some of the layout issues you mentioned...

Barrier appears to handle PC switching only for the keyboard and mouse.

Sorry, probably not entirely on topic and can't answer anything reliable about the multimonitor stuff, but a tip regarding the 2 mice and 2 keyboards for the 2 different computers: use this: https://github.com/debauchee/barrier It's oss multi-os software that lets you use one mouse and keyboard (server) on several PCs (clients) easily over your LAN.

Barrier is a free and open source alternative.