Add support to devel/libhyve-remote. (VNC Server)

[araujo]

Summary

The libhyve-remote aims to abstract functionalities from other third party libraries such like libvncserver, freerdp and spice to be used in hypervisor implementation. With a basic data structure it is easy to implement any remote desktop protocol without dig into the protocol specification or third part libraries, you can check some of our examples.

We don't static link any third party library, instead we use dynamic linker and we load only functionalities that we believe is necessary to launch the service.

Our target is to abstract functionalities from libvncserver, freerdp and spice. Right now libhyve-remote only supports libvncserver. It is possible to launch a vnc server with different screen resolution as well as with authentication.

With this patch we implement support to bhyve use libhyve-remote that basically abstract some functionalities from libvncserver.
We can:

• Enable wait state.
• Enable authentication.
• Enable different resolutions.
• Have a better compression.

Also we add a new flag to be called with -s that is vncserver, if the libhyve-remote library is not present in the system we fallback to bhyve RFB implementation, ex.:
-s 2,fbuf,tcp=0.0.0.0:5937,w=800,h=600,password=1234567,vncserver,wait

Test Plan

Tested with (guests):

• Windows10.
• Fedora Workstation.
• FreeBSD12.

Tested with VNC (clients):

• RealVNC.
• net/tigervnc.
• net/tightvnc.

[araujo]

Update manpage.

[bcr]

Small comment on the man page change.

usr.sbin/bhyve/bhyve.8

197

... provides a VNC server.
or
... provides the VNC server.

[araujo]

Address @bcr change request.

[bcr]

OK from manpages. Thanks!

[grehan]

I'm looking at this now. I think there will need to be some changes in the mechanics for this, and also the abstraction. I'll write up something longer with more detail.

On naming - the term "vnc" was explicitly avoided in bhyve since much of the display code could be used with any remote protocol.

[grehan]

Some high-level comments:

• the shared library interface is a bit fragile, since it searches for only symbol names and seems to imply a copy of an internal data structure (the vncserver_softc struct). A better approach would be something like bhyveload, where there is a single struct that contains a version and function pointers. That should be exported to a header file (along with any other structs used in the api) and go somewhere like <bhyve/extvnc.h> or similar.
• the 'enable_http' function isn't used and maybe should be removed.
• the frame-buffer differencing engine has been copy-pasted into vncserver.c. A better approach might be to make the existing rfb code an implementation of the function pointers, and allow an override to an external shared library on the command line (perhaps named to allow alternate ones). The differencing engine would then just call a function pointer, allowing a single copy of the code to be used.
• the hard-coded path to the ports shared library should at the minimum be a #define, and better, extracted from the command line.

There are some unnecessary style changes that create additional extraneous diffs - these should be removed.