don't panic

Scenario A: Using windows-gaming within some scripted thing (unlikely but possible).

Scenario B: You'd like to do something the wizard doesn't directly support, e.g. slightly modifying my setup later without starting over entirely.

The original design intended for you to just edit the config, but TOML is not that popular and it's not always enough (config files and stuff).

Of the Ctrl+Alt+Ins sequence, you would usually still be holding Ctrl and Alt when the keyboard is disconnected, causing those keys to be stuck in the VM with most keyboard drivers.

Could hack around this by just delaying the VM exit but usability might suffer.

• Set system to auto passwordless login (we rely on this)
• Disable xbox game dvr in autorun (HKCU\System\GameConfigStore\GameDVR_Enabled = dword:0)
• Disable fast boot (#32)

The monitor command line is not a stable interface, so we should switch to qapi instead.

things like RAM just overwrite but don't keep adding the same disk over and over again

Accessing /dev/vfio/1 needs sudo permissions, which the setup does not have in user-mode.

For example we could try to reestablish the connection / create a new one.

cc #42

• Query what the user wants in the wizard
• Automatically mount the share from the guest agent

I wanted to avoid running smbd as root at all costs which is why we're currently always invoking it through sudo:

    write!(usernet,
           ",guestfwd=tcp:10.0.2.1:445-cmd:sudo -u {} -- smbd --configfile {}",
           samba.user,
           samba_cfg.display())

Now that user mode is strongly preferred, this makes significantly less sense: This sudo invocation will only work if:

1. You are root (system mode)
2. It's the same user (so sudo does nothing)
3. You manually configured sudo so the current user has passwordless sudo to the target user (who even does that)

Depending on how much we want to support or neglect system mode, 1 may be a reason to keep it. For 2 it's completely useless however. 3 affects a tiny portion of our already nonexistantly small userbase so I guess we can ignore it.

Before switching to tokio / futures / mio, we had the structure of Pollables being separated into non-critical tasks, meaning they can die without any further implication, and critical tasks, which would end the whole application if one fails or all end successfully.
With tokio, we can achieve the same by spawning non-critical tasks into a Handle and joining all criticals tasks into a single future which is executed with Core::run.

Add support for all of these formats: https://en.wikibooks.org/wiki/QEMU/Images#Image_types

Log stuff like the executed qemu command with log and env_logger.

We need a cli to better control the setup, startup process and implement a control client ( #1 ). I'd suggest using clap. It has support for subcommands which we can use to create the following commands:

1. windows-gaming setup to invoke everything setup related.
2. windows-gaming start/run to start qemu and run the driver.
3. windows-gaming control for #1

If start/run is executed, we somehow need to check if the setup has already been run / verify the config file. What is your opinion on that?

So far we're only doing this for USB devices (creating our own bus and assigning ports) but ideally we would control the entire device tree (PCI root ports etc).

Consider using the -readconfig option for this as passing all devices on the command line kinda sucks.

See also this sample config.

https://github.com/whitequark/rust-xdg

Apparently there might be compatibility issues with floppy.

The floppy was neat because it contained exactly what we need (the only alternative they offer is the full ISO with i386 and all drivers and it's literally 50x the size) but that doesn't matter when it doesn't actually work.

I'd suggest repackaging the vfd to an iso (like mcopy -i virtio-win_amd64.vfd -s ::/amd64 .) but that's an mtools dependency so not sure.

This is necessary on some system configurations.

• Figure out exactly where (optional)
• Systemd unit or similar to fix things without making the machine unusable (create a new console in case efi is the only one)

Action-performing methods should return a future which resolves as soon as the performed action is confirmed by qemu / the GA.

• io_attach: Resolves when {return: {}} is returned by qemu. When waking up from suspend it resolves after attaching the devices. If all devices are already attached, an instataneously resolving future will be returned.
• io_force_attach: ~
• io_detach: Resolves when DEVICE_DELETED is returned by qemu as often as the number of devices to be disconnected.
• action: Resolves based on the previous action taken.
• suspend: Resolves when SUSPEND is returned by qemu.
• shutdown: Resolves when SHUTDOWN or SUSPEND_DISK is returned by qemu.

Answering parts of "Step 6: VM setup" and pressing Ctrl+C previous input in that step is not saved.

• Simple mode - Basically xsel --clipboard: You can pipe into and out of it.
• Luxury mode: Daemon that keeps clipboard contents synchronized at all times (needs to be X11/wayland-aware obviously).

make sure all bindings worked, not just any of them

~/Win10_1607_EnglishInternational_x64.iso is not accepted.

Keep the socket connection open until the command is fully executed. For example when calling suspend, only close the connection once Windows is fully suspended and qemu reports back SUSPEND.
cc #64

We should only offer to autocall mkinitcpio if we know you're using it, right now this is bugged

What we can (and probably should) ship is a systemd service unit for both user and system/root mode. It just runs windows-gaming-driver with the default config. However, this is only fully implemented once we make sure that the service never attempts to run the wizard. (isatty(3) is probably the most straightforward solution here)

The setup wizard can then even enable the unit for you.

Implementing full daemonization is very useful for non-systemd distributions (or they would have to resort to some wrapper like FreeBSD's daemon) but I guess that's more of a backlog thing.

• udev picker to select mouse and keyboard
• support headless setup
• support passing through other USB devices as well
• allow more granular selection and setup of USB devices to select which flags should be set (e.g. permanent, bind ById or ByPort, …)

• Make the guest agent installer disable it
• Create our own version that boots windows with the host and then puts it to sleep if the user doesn't enter for ~1min.

Add a system to execute sh commands on the following events:

• pre-startup
• post-startup
• pre-shutdown
• post-shutdown

Let the user specify optional strings inside the config file for these hooks to be executed inside sh -c '…'.

key: hotkey.key.clone(),

As we already clone the whole hotkeys vector, use into_iter instead of iter so we don't need to clone the key again.

The config file's directory defaults to ~/.config/windows-gaming-driver/. If windows-gaming-driver does not exist, the setup panics.

Again something very very tricky as this depends entirely on the user's networking software. Bridged networking should be fine for most users, but NAT (like VirtualBox does it) should actually work for everyone so it might be a little better. No clue how to set this up though.

And perhaps some other signals as well

Currently the host side of our software containing the driver and setup is called windows-gaming-driver. As it was first planned to only contain the actual diver, we should think about a new name for both the folder and the cargo package name. Here are some of my horrible suggestions:

• host-agent
• host
• windows-gaming

When switching from nvidia to intel graphics, one needs to remove all nvidia packets and replace them with mesa-libgl (and lib32-mesa-libgl if using multilib). Also /etc/X11/xorg.conf needs to be removed / adapted to not use nvidia anymore.

Currently different errors are all over the place and expected everywhere, which is bad style. Instead error_chain should be used to unify different errors.

After a suspend when waking up the driver receives a ga_hello, on which it sends all hotkeys to the GA. As the GA has already registered those bindings, it errors:

client says that it's suspending
{"timestamp": {"seconds": 1497008566, "microseconds": 825259}, "event": "SUSPEND"}
IO entry requested!
{"return": {}}
{"timestamp": {"seconds": 1497008571, "microseconds": 28995}, "event": "WAKEUP"}
client is now alive!
{"return": {}}
{"return": {}}
HotKeyBinding failed: bind error: System.ComponentModel.Win32Exception (0x80004005): The operation completed successfully
HotKeyBinding failed: bind error: System.ComponentModel.Win32Exception (0x80004005): Hot key is already registered
HotKeyBinding failed: bind error: System.ComponentModel.Win32Exception (0x80004005): Hot key is already registered
HotKeyBinding failed: bind error: System.ComponentModel.Win32Exception (0x80004005): Hot key is already registered
HotKeyBinding failed: bind error: System.ComponentModel.Win32Exception (0x80004005): Hot key is already registered

Even if it's just shell scripts calling netcat, we need something that allows you to actually use the control socket.

Right now, we just blindly assume that they exist if the user attempts to use them. Obviously, this is bad.

• qemu GTK (sidenote: maybe support qemu's SDL GUI as well?)
• samba
• windows10-downloader

(Issue was renamed - original text below)

A dependency of windows-gaming-git is qemu-headless. From its description:

QEMU without GUI

Therefore running qemu with a visual setup does not work resulting in qemu-system-x86_64: -display gtk: GTK support is disabled.

One big issue is that Windows really doesn't like it when you just suspend the host and usually/always crashes.

For systemd users we can just use a sleep inhibitor (this mess shows how to do it).

Supporting bare pm-utils for non-systemd users is nice to have as well.

In any case, I believe this needs guest agent support.

When running the setup in user mode, it can't access /dev/vfio/X. The user manually needs to add himself to that group. This process should be automated.