On 2/23/26 16:27, Leo Li wrote:
Really nice debuging work, thanks for catching this! Ideally, the cursor event should be delivered when hardware latches onto the new cursor info and starts scanning it out. The latching event fires an interrupt that should be handled by dm_crtc_high_irq(). dm_pflip_high_irq() handles an interrupt specifically for when hardware latches onto a new fb address; I don't think it actually fires when there's a cursor-only update. I think if we really want to do it right, we can have another "acrtc_attach->cursor_event" just for cusror-only updates, and deliver the event in crtc_high_irq(). In any case, I don't foresee any major issues with delivering the event early. And since it fixes an ongoing issue: Reviewed-by: Leo Li <[email protected]> Thanks! Leo
Thanks for the review. Further testing confirms that both this patch and increasing the dGPU vblank offdelay (from 2 frames to ~50 frames) independently eliminate the flip timeouts in my testing. Both work by reducing the frequency of vblank disable/re-enable cycles, basically either could be an interim fix.
Your deferred vblank enable/disable series https://lore.kernel.org/amd-gfx/[email protected]/T/#t looks like it could be the proper solution going forward instead (haven't tested it).
