Fails need a circuit breaker to avoid soft-locking

[DravenFrostfall]

Describe the bug
If erroring out, for example with this error, mouse key events will be soft-locked as long as the terminal is getting spammed.

So we need a cutoff/ poison message handling so as to not spam the log forever and soft-locking the system.

[baronsmv]

Hi, @DravenFrostfall. Thank you for submitting this issue.

That seems like a problem with the capture library, while the mouse mapper still got going. Can you describe the steps that led you to this? That could help me understand where to apply the break.

v0.2.10 introduced a new capture module that it's a bit on the experimental side, and here it's failing non-fatally. I have noticed some collisions between X11 threads (which I'm currently fixing on a developing branch), so that could be also the case here.

[DravenFrostfall]

Launched the game, ran upscale in the terminal, tab-out once.

[baronsmv]

Hi, @DravenFrostfall.

Sorry for the absence on this issue. Since v0.3.0, the upscaler migrated from Xlib to XCB, to avoid any X11 thread collision, which could have caused the FrameGrabber constant failure here (although I couldn't replicate it in my setup).

Does the latest version still gives you this soft-locking issue?

[DravenFrostfall]

Oh yeah, but it's more tied to the Proton version than anything. The upscaler is super picky about the proton and version.
If I use Proton-GE for example, I will get a white screen, and it will soft lock the system, the terminal will spam itself with some red text until I force a log-out, since no other input or window can be grabbed.

[baronsmv]

Interesting. I did a bit of research on the error itself. This is a SHM-specific issue. Relevant discussions: here and here, although without any clear solution.

Also from docs:

XShmPutImage combines an image in memory with a shape of the specified drawable. If XYBitmap format is used, the depth must be one, or a ‘‘BadMatch’’ error results. The foreground pixel in the GC defines the source for the one bits in the image, and the background pixel defines the source for the zero bits. For XYPixmap and ZPixmap, the depth must match the depth of the drawable, or a ‘‘BadMatch’’ error results.

So, possibly tabbing out with some Proton versions changes the window visual in a particular way that the shared memory segment needs to be recreated completely, after a depth-mismatch.

I added a general circuit breaker to any FrameGrabber consecutive issue, but also made the C capture lib a bit more resilient on that end: it will now detect any mismatch like this and try to recover automatically. I'm not completely sure it can, but let's try.

Please upgrade to v0.3.1.post5 and test this specific case.