Wayland support

[balsoft]

Currently appvm uses X11/Xorg. This issue is for experimentation with Wayland, with eventual goal being to have optional Wayland support without Xorg on the guest, and maybe to pass windows to the host more directly with waypipe. Possible approaches

• [ ] cage (or other simple wayland compositor) Cage is a simple compositor that starts a single application full-screen and quits as soon as that application quits. Problems: no support for automatic resizing or other features of SPICE. It's a deal-breaker, as the almost-native experience that we thrive for is ruined by the need to capture pointer and keyboard, and the window does not resize correctly. Possible solution: write a daemon that reacts to SPICE events. Things done

  • [x] mingetty autologins user, cage starts from loginShellInit Problems: not very fast, feels bodgy
  • [ ] cage replaces getty, logs in via a PAM module (as suggested upstream)
  • [ ] Make cage understand SPICE (either by patching cage or by writing a shim`
  • [ ] Find another wayland compositor that already knows SPICE

• [ ] GNOME3 Gnome3 supports SPICE natively or maybe not, see the following

  • https://www.reddit.com/r/qemu_kvm/comments/d2yqy6/anyone_had_problems_resizing_guests_with_spice/ (clearly suggests that gnome on wayland doesn't work with SPICE)
  • https://bugzilla.redhat.com/show_bug.cgi?id=1266484 (clearly suggests that it does work)

  Potential problems: SPICE not working, very heavy, not sure if it can run a single full-screen app without all the fuss (see https://help.gnome.org/admin/system-admin-guide/stable/lockdown-single-app-mode.html.en, not sure if this is for wayland or for X) Things done:

  • [ ] GDM starts a wayland gnome kiosk session Problems: really heavy, might be buggy
  • [ ] dbus-launch gnome-session from loginShellInit Problems: might not support SPICE or whatever

• [x] waypipe without compositor It might be possible to run waypipe on a guest without having a compositor at all. This would solve most of our problems with SPICE, since all of the window management now happens on the host. I have not looked into waypipe, so maybe I'm wrong, but this looks like the most elegant and "correct" solution of them all. Problems: might not actually run without a compositor, might be slow, requires networking between guest and host, might be insecure Investigation process:

  • [x] waypipe can run without a compositor (tested with waypipe ssh headless-server konsole, where headless-server only has waypipe and konsole installed)
  • [x] Figure out how host and guest can talk to each other
  • [x] Figure out how to make guest's waypipe server talk with host's waypipe client (using -s argument and socat)

  Things done:

  • [ ] Run a guest with waypipe and the application installed, then run waypipe ssh user@guest application from the host (we have to figure out credentials)
  • [x] Run waypipe client on a host, run guest with waypipe server CMD, make them communicate (I like this solution the most of them all)

[balsoft]

I've made waypipe work. It appears to function just as I assumed it would.

[jollheef]

The idea of using something like Waypipe for Wayland support (as additional, keeping current implementation as the main one) sounds good.

However, I'm concerned about Waypipe implementation itself. The quality of code is quite below my expectations.