Return to

Integration of LG client?

So I’ve been using Looking Glass as my primary development (unreal engine) workstation for a few days now. No more multiboot hell! The core functionality is working great. However, being a product in development, its a little rough around the edges. It’s proving to be very worth the effort to set up which was a little tricky for me (a linux novice). But about those rough edges-

For example, currently my routine to get things started is 1, start the VM. 2, ‘wait a while’ for the VM to boot. 3. attempt to start the LG client app. 4, if it kicks, retry step 3 until it connects. (This is on the latest build.) I think b1rc5 waited, but regardless - being a lazy windows user, I’d like to script starting & connecting LG to a VM and link that to a dock icon. Problem is (I tried) I can’t just wait until the spice port opens before connecting, that’s long before windows is booted and the LG server is running. Is there a way to detect from a host script when the LG server is running in the VM? Something a script can poll on or wait for in some way? That way I can script something that starts the VM, waits for LG server to start, then connect to it with the client. Eventually autostart that on boot.

This makes me wonder, are there any plans to integrate the Looking Glass client app into virsh-viewer or virt-manager in the future? The reason I ask is that at some point I noticed that if I left the QXL driver enabled (as opposed to ‘none’), a spice client can see the vm post & boot process like any VNC+ client can up until the LG server app takes over. It would seem a natural fit to just merge LG into the viewer and create a natural transition from spice/vnc to the hardware-accelerated view. (probably just disable the QXL adapter in windows as a part of the setup process to avoid multi-screen issues) This potentially could file a lot of the rough edges off things, simplify usage for the unwashed masses, and ideally lead to an eventual pull request merge into qemu/libvirt and gain very wide adoption. (?)

1 Like

Agreed, current master has gone through a major rewrite of the core functionallity and this wait to connect feature will be returning.

Simply put, no. If you want to see this you would have to try to get the QEMU/VirtSH guys interested enough to implement it, but IMHO you will not see much progress on this as they do not even agree with our use of the IVSHMEM device. Windows support for this use case seems to be very low on their priority list.