Modified to reset and close the Stream Deck on panic or termination signal

[henryso]

1. I deferred a reset/close of the Stream Deck on return from main
2. I changed the os.Exit calls in the fatal and fatalf functions to panic so that the defer from above is called
3. I added signal handling to eventLoop to catch Control-C and kill -15 so that the defer from above is called

[muesli]

I wonder if we shouldn't just try to reset the device once after opening it? After closeDevice we're terminating deckmaster anyway, as we return an error below.

[henryso]

Resetting the device puts it back (at least visually) to it's power-on state, with the Elgato logo. If we don't reset before closing it, The screen is left showing what it had before the close, which might have stuff like a frozen clock or CPU/Memory widget.

[muesli]

That's why I suggest resetting it once after opening and removing the closeDevice calls except the deferred one in line 204. This should have the same effect then: if we encounter any error during initialization (lines 174, 181, 189) we would have already reset the device and can just return the error.

[henryso]

The problem here is that what needs to be done is a close of the device (dev.Close()) more than a reset of the device. If dev.Close() is not called, then the Stream Deck will need to be unplugged and replugged. In order for this to work, I initDevice() will need to return dev (rather than nil) along with the error so that main can close the device.

The code would then look like

dev, err := initDevice()
if dev != nil {
   defer closeDevice(dev)
}
if err != nil {
    fatal(err)
}

Sound OK?

[muesli]

Understood, but instead of closing the device and then shutting down again, maybe we could just try to close the device and re-open it inside Deckmaster, if we encounter an error during initialization? That would prevent the user from having to re-plug the device or restart Deckmaster. What do you think?

[henryso]

This might not be what you're getting at, but in my case, when the device is in a bad state (pretty much when dev.Close() is not called), it stays in that bad state until I re-plug the device.

In using deckmaster so far (which is only for a few days), those initialization operations (get firmware version, reset, set brightness) have never failed, but that doesn't mean they won't ever fail. What I'm trying to say is that I probably don't care too much how this is handled here, but at least we should dev.Close() so that there's less chance of needed a re-plug at this point.

As for a retry of initialization, I suppose that's possible, but I personally don't think it's necessary. At initialization time, it would be pretty obvious if things are not working, and the user could start troubleshooting. If it's hardware failure, we probably don't want to keep retrying "known good" things that are suddenly failing.

I've pushed the change modeled on what I said above, but I'll change it to whatever you feel is best here since I don't feel too strongly about how things fail at initialization time.

[muesli]

Thank you, starting to understand the situation a little better now!

[henryso]

Let me know if that's not what you want.

[henryso]

@muesli Is there something else you would like me to do for this PR?

[muesli]

@muesli Is there something else you would like me to do for this PR?

All good, I'm just trying to improve the situation a bit, introducing a generic shutdown chan so we can make use of defers in main without having to rely on panic. Will probably push a few changes to your branch soon!

[muesli]

Ok, added on top of your changes and cleaned up the error handling a bit. Thank you for your contributions!