Added some quality of life features

[NeoTheFox]

I've added two features that I found very useful in my setup.
First one is to use sudo for ddcutil - I don't feel comfortable just giving rw permissions to everything to just write to i2c bus, so a good solution is to use sudo just for ddcutil. By adding
%wheel ALL=(ALL) NOPASSWD: /usr/bin/ddcutil
to the sudoers file you can make sure that it can be called without any password prompt. This presents some security implications on its own, but I think it's nice to have as a workaround.

The second feature is to check if the guest is running before switching the kvm. Sometimes I forget to start the guest, and having to manually switch back the monitor just to do it can be somewhat frustrating.

[alexbakker]

Thanks for the PR!

I'm not really a fan of the dependency on sudo. I would be more concerned about someone finding a vulnerability in ddcutil and escalating privileges to root, than someone accessing the i2c devices of my monitor. I use the following simple udev rule to only give logged in users access to the i2c devices: KERNEL=="i2c-6", TAG+="uaccess".

Do you think we need an option in the config file to enable checking whether the guest is running, or can we just do that by default and leave the option out?

[NeoTheFox]

The udev rule would allow every process running as user to write to i2c-6, and that's not something I want to do, because some devices have fragile firmwares, and writing garbage to their i2c bus can cause software bricks. Without any gatekeeping you can do it accidentally, like using dd on a wrong /dev/sd* device. Ideally ddcutil would be a daemon running as either root or another group that has the rw rights to i2c, but that's out of the scope of this script. Note that this option is still just an option, and I'm not suggesting to enable it as a default behavior. Other software solutions like PSD also have this workaround, and to be fair chances of me writing garbage to i2c bus are higher than chances that someone would write malware targeting ddcutil specifically.

I think checking if the guest is running is preferable to not checking, but there is one edge case I'm worried about, and that's switching to the guest ASAP to catch it at boot time. Some operating systems like Windows have hotkeys you can press in a very brief window during boot to get to hidden options. Right now the monitor output would switch, but the usb passthrough would just silently fail, so maybe we can try to somehow do it continuously until it happens, or watch the domain?