Hi Thomas, > Yeah, what's the cause of it? Switching off features does not fix any > bugs or improve the status quo.
You are right that the module parameter is only a workaround for users affected; it does not fix the underlying scheduling problem. The cause is that the synthetic vblank timer is used to pace completion of atomic updates triggered by dirtyfb, in addition to providing synthetic vblank events. In Xorg's software-cursor path, pointer motion damages the primary framebuffer and the damage is instantly submitted via DRM_IOCTL_MODE_DIRTYFB. The Hyper-V dirtyfb path performs a synchronous atomic commit, and with the vblank timer enabled that commit can wait for the next simulated vblank. Under continuous pointer motion, these commits dominate the update path and delay normal client updates, resulting in sever frame-rate drops. This particular regression results from the combination of the blocking dirtyfb path, synthetic vblank pacing, and the absence of a Linux DRM cursor plane in Hyper-V. While the Hyper-V video protocol does have a hardware-cursor command path, the upstream hyperv_drm driver currently exposes only a primary plane. Cursor plane support was deferred during the initial upstreaming [1]. Without a cursor plane, Xorg has to fall back to software cursor-rendering path and it competes with periodic graphical updates on the primary plane. So the proper long-term fix could be adding cursor plane support in the Hyper-V DRM driver, which may take some time. Providing that the stated purpose of the offending commit is to rate-limit display updates, while its current implementation regresses the existing software-cursor path, I think adding a switch or reverting the commit until the requested features in the driver is ready, is a reasonable short-term fix. > We had another fix for a problem with vblank timers: > > https://lore.kernel.org/dri-devel/[email protected]/ > > Did you validate that this fix is unrelated? Yes I tested that fix and confirmed that it is irrelevant. It solves issues with excessively long frame durations, however this problem is found in normal frame updates (in my case 60Hz / 16.7 ms per frame, way below INT_MAX). Best regards, Lanfeng Wei [1] https://lore.kernel.org/dri-devel/[email protected]/
