Nixpkgs: QEMU has no option to be compiled w/ GTK support

[michalrus]

Issue description

When QEMU is launched with the default SDL rendering in a tiling WM setting, its window is stretched without keeping its aspect ratio, which looks terribly unreadable in 2017.

Steps to reproduce

1. Launch a QEMU VM (possibly created by nixos-rebuild vm).
2. Resize its window.
3. Look at the fonts.

Technical details

• System: 17.03.1844.83706dd49f (Gorilla)
• Sandboxing enabled: yes

[dtzWill]

This looks easy to enable, just adding gtk3 and gettext as build dependencies:

From b91232e5738baf1aeb85f102128260ee26ee8407 Mon Sep 17 00:00:00 2001
From: Will Dietz <[email protected]>
Date: Sun, 29 Oct 2017 13:24:30 -0500
Subject: [PATCH] qemu: optional gtk3 support, enable as qemuGraphical

---
 pkgs/applications/virtualization/qemu/default.nix | 2 ++
 pkgs/top-level/all-packages.nix                   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/pkgs/applications/virtualization/qemu/default.nix b/pkgs/applications/virtualization/qemu/default.nix
index cb0f772ada3..9b4b73db847 100644
--- a/pkgs/applications/virtualization/qemu/default.nix
+++ b/pkgs/applications/virtualization/qemu/default.nix
@@ -8,6 +8,7 @@
 , seccompSupport ? stdenv.isLinux, libseccomp
 , pulseSupport ? !stdenv.isDarwin, libpulseaudio
 , sdlSupport ? !stdenv.isDarwin, SDL
+, gtkSupport ? false, gtk3, gettext
 , vncSupport ? true, libjpeg, libpng
 , spiceSupport ? !stdenv.isDarwin, spice, spice_protocol
 , usbredirSupport ? spiceSupport, usbredir
@@ -47,6 +48,7 @@ stdenv.mkDerivation rec {
     ++ optionals numaSupport [ numactl ]
     ++ optionals pulseSupport [ libpulseaudio ]
     ++ optionals sdlSupport [ SDL ]
+    ++ optionals gtkSupport [ gtk3 gettext ]
     ++ optionals vncSupport [ libjpeg libpng ]
     ++ optionals spiceSupport [ spice_protocol spice ]
     ++ optionals usbredirSupport [ usbredir ]
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 596051f4ea7..9727d6cd5d9 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -16188,6 +16188,7 @@ with pkgs;
     inherit (darwin.apple_sdk.frameworks) CoreServices Cocoa;
     inherit (darwin.stubs) rez setfile;
   };
+  qemuGraphical = qemu.override { gtkSupport = true; };

   qgis = callPackage ../applications/gis/qgis {};

-- 
2.14.3

I'm not sure how we'd like this to be best integrated with use of QEMU in the tree but good news is it looks easy technically (tested that the result had working gtk support).

Thanks, BTW, didn't realize QEMU had a GTK GUI! :)

[michalrus]

@dtzWill, thanks!

But are you sure qemu -display gtk … worked without adding --enable-gtk to configureFlags?

I tried to do this in a vm-configuration.nix like that:

{
  system.build.qemu = with pkgs;
    lib.overrideDerivation qemu_test (oldAttrs: {
      buildInputs = oldAttrs.buildInputs ++ [ gtk3 ];
    });
}

and it rebuilt correctly, but no GTK support.

If you do this instead:

{
  system.build.qemu = with pkgs;
    lib.overrideDerivation qemu_test (oldAttrs: {
      buildInputs = oldAttrs.buildInputs ++ [ gtk3 ];
      configureFlags = oldAttrs.configureFlags ++ [ "--enable-gtk" ];
    });
}

… then ./configure fails:

configure flags: --prefix=/nix/store/p184f2765l7y69i0kyzm99jsahiwks0r-qemu-x86-only-for-vm-tests-2.8.1.1 --smbd=smbd --audio-drv-list=alsa,pa,sdl, --sysconfdir=/etc --localstatedir=/var --enable-numa --enable-seccomp --enable-spice --target-list=i386-softmmu,x86_64-softmmu --enable-linux-aio --enable-gtk 

ERROR: User requested feature gtk
       configure was not able to find it.
       Install gtk2 or gtk3 devel

builder for ‘/nix/store/shr0ijr4im87lpxhx96mpyfb97y02p3x-qemu-x86-only-for-vm-tests-2.8.1.1.drv’ failed with exit code 1

It will also fail when you use gtk3.dev or gtk2 or gtk2.dev (gettext and gnome3.vte don’t help either).

[dtzWill]

I actually don't get a qemu binary?

I pushed my branch (recent master with the patch I posted previously), so we can be sure we're working with the same code:

https://github.com/dtzWill/nixpkgs/tree/experimental/qemu-gtk

Building qemuGraphical yields the following store path:

/nix/store/if0addlz6zwyykas6k4vlza5cvhixaz2-qemu-2.10.1

I actually didn't specify -display gtk, it just used the GTK interface by default apparently!
That said, inspecting the output of --help shows that should work.

I'll poke at this a bit more, not sure why we're seeing different results...

[dtzWill]

Noticed you were overriding qemu_test, hoped that explained the difference, but building it with gtkSupport = true; seems to work here.

Ok so I can confirm nixos-rebuild build-vm with the snippet you gave (put in configuration.nix) does not work--configure doesn't seem to find "gtk". This is on 17.09.

Something about master vs 17.09 is the key, apparently? For example, this gives GTK-capable QEMU goodness:

nixos-rebuild build-vm -I nixpkgs=https://github.com/dtzWill/nixpkgs/archive/experimental/qemu-gtk.tar.gz

[michalrus]

So my snippet doesn’t work on my 17.03, either. =(

Thank you for the effort, @dtzWill! ♥

I just applied your patch directly to my 83706dd49f4 system and it didn't work.

It might be worth adding that configure flag to it, for further tests. Then ./configure fails early and we don’t have to wait for the whole compilation.

[michalrus]

OK! So I confirm that on 17.09 3ff874c06af1ca4ab01a374a13eb20697f3f9b31 this does work:

      qemu_test.overrideDerivation (oldAttrs: {
        buildInputs = oldAttrs.buildInputs ++ [ gtk3 gtk3.dev gettext gnome3.vte-ng ];
        configureFlags = oldAttrs.configureFlags ++ [ "--enable-gtk" ];
      })

So maybe this should be added to the QEMU package?

It looks muuuuuuch prettier, no ugly SDL scaling, 1 px in guest is 1 px on host, see in upstream: https://bugs.launchpad.net/qemu/+bug/504368

/cc @grahamc @volth @oxij @andir @dezgeg @fpletz

[oxij]

Ok. Will do.

[xeji]

Anyone working on this? If not I'll be happy to prepare a PR because I'd like to have it as well...

[oxij]

I added gtkSupport ? true option to the qemu expression verbatim from the override by @michalrus above to my branch, but I have not tested it myself yet and then I forgot that I wanted to test it myself. TBH, I'm kinda lazy to PR that change right now since it's tiny (and I have not tested it) and I prefer to PR things in batches for efficiency.

If you need it, you should just completely ignore me and PR the change you tested yourself.