Window on workspace moved back to hotplugged monitor not getting frame callbacks

[ids1024]

Reproduction:

• Start cosmic-comp, with two monitors
• Open a terminal on the first monitor, and open something like vkgears on the second
• Turn off second monitor, and turn it back on, so workspace is moved and moved back

This can result in a state where the (vkgears) window on the second monitor is frozen.

When the window is like this, it updates at 1fps when the cursor is moved, but even the 1 fps throttled frame callbacks don't occur when there isn't input. Opening another window on the same workspace causes it to update at 1 fps if the other window is redrawing.

Switching to a different workspace and back on the affected monitor fixes the issue. Going through the code that's called in that case, it surprisingly seems to be related to animations. If animate is set to false in WorkspaceSet::activate, switching the workspace and back does not make the window start drawing at a normal frame rate. So somehow setting previously_active triggers some later code that fixes the state, but it's unclear how...

Related issues:

• Drag surfaces also seem to have issues with not getting frame callbacks when there's not mouse movement. If I try dragging vkgears.
  • If I drag it to another output, it redraws at a normal frame rate while the mouse is moved. But if I without releasing the mouse, move it to the first output, it is also throttled to 1 fps
• The workspace doesn't seem to be moved back to the second output the first time I try unplugging the monitor and re-connecting it? So in testing I have to do this twice. Odd, but a separate issue.

[ids1024]

Okay, even weirder: instead of setting animate to false, setting previous_idx to None in src/backend/kms/surface/mod.rs also makes switching workspaces not fix this. So somehow calling workspace_elements is what's fixing the state of the surface?

[ids1024]

In render_input_order_internal, this seems to be related to the offset of the Stage::Workspace.

So when it renders the window with a different/non-zero offset, somehow that fixes the rate at which it gets frame callbacks.

[ids1024]

(I was assuming activate ended up calling or setting something that the code moving workspaces to a different output didn't, and it would be simple to add that there once it was identified. This is stranger than I expected, but hopefully useful context, though I'm not sure what to make of it or where to go from here...)

[ids1024]

COSMIC_DISABLE_DIRECT_SCANOUT=1 doesn't seem to change things, so this isn't related to direct scanout.

But somehow relates to the offset used with RescaleRenderElement.

[ids1024]

Looks like the reason offset impacts this is that default_primary_scanout_output_compare compares how much area of the surface appears on an output. So shrinking that area then growing it again triggers switching to the new output as the scanout output.

The issue where workspaces aren't always moved back is probably because this laptop dynamically adds DRM connectors, and the numbering isn't entirely consistent. Maybe we could do better to identity the "same monitor", though that's inherently imperfect.