FScreen: fix crash on transient empty RandR topology (lid reopen)

[gtnoble]

When a laptop lid is reopened, the kernel disables and then re-enables the internal panel. If XRRGetMonitors() returns n=0 during that window, scan_screens would mark every monitor MONITOR_DISABLED, and the next FindScreenOfXY call would hit exit(106), killing the WM.

Two fixes:

1. scan_screens: when randr_initialised and n <= 0, retain the existing monitor set and return early instead of clearing all state.
2. FindScreenOfXY: degrade to monitor_get_global() rather than exit(106), as defence-in-depth against any residual path hitting an all-disabled queue.

Also add a NULL-check in monitor_check_primary() on RB_MIN to avoid a potential null dereference on genuinely empty queues.

[ThomasAdam]

Hi @gtnoble

Thanks, but I'm struggling to see how this is a problem, to be honest.

Also, how much AI are you using here?

[ThomasAdam]

Also, I don't want to retain the monitor list, as there's no guarantee it's going to be the same. All FVWM is doing here is responding to the correct order of events.

[gtnoble]

Hi @gtnoble

Thanks, but I'm struggling to see how this is a problem, to be honest.

So, the issue is that when I close the laptop lid, there are no monitors available, which causes FVWM to crash. Making FVWM more robust to the situation when there is a transient absence of monitors would prevent this issue. This fix resolves the issue for me. If this is not the fix you would use, perhaps you could consider this as a bug report.

Also, how much AI are you using here?

I will freely admit to using AI. If this is a problem, I understand and respect that and will refrain from submitting PRs in the future.