Drakulix
commented
3 months ago I agree that the current behaviour isn't optimal.
Should we make sure a panic in a thread kills the whole compositor, again? Or can we do something to try to re-spawn a thread for rendering an output (and hope it doesn't repeatedly panic)? Not sure what other options there might be.
Panic'ing everything seems to be a solution to make it at least visible, but that is still much more disruptive and potentially breaks applications.
Restarting might be an option, but I don't want to end up in a busy loop like situation, where we re-try continuously either. If we do that we should have some kind of counter and reset that again, once the thread has been running for some time.
Alternatively or after hitting some max value for the retry counter, we could just set the output to disabled at least in multi-output situations. If we only have one output, we might want to fall back to panic'ing, even though we explicitly added support for removing all outputs... sigh
danik292
With https://github.com/pop-os/cosmic-comp/pull/546, panics that would previously have killed cosmic-comp now only kill the DRM thread for that surface.
This is potentially good, but maybe a bit confusing? The logs will indicate a panic, but otherwise it's unclear what happened. The output just stops working.
Should we make sure a panic in a thread kills the whole compositor, again? Or can we do something to try to re-spawn a thread for rendering an output (and hope it doesn't repeatedly panic)? Not sure what other options there might be.