On Tue, Oct 20, 2026 at 01:48:58PM +0200, Thomas Zimmermann wrote: > Hi > > Am 19.10.26 um 20:38 schrieb Hamza Mahfooz: > > On Mon, Oct 19, 2026 at 06:03:55PM +0200, Thomas Zimmermann wrote: > > > Hi > > > > > > Am 19.10.26 um 17:40 schrieb Lanfeng Wei: > > > > 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. > > > The problem is that module parameters are impossible to remove in > > > practice. > > > Once in place, someone always depends on it. They also increase the number > > > of states to test. Avoiding them is usually a good idea. Especially as > > > workarounds for bug or regressions. > > > > > > > > > I'm not familiar with the Hyper-V protocol, so I have a question. Why is > > > it > > > hard to implement cursors? From the link at [1], I assume that cursor > > > support was left out because the simple-kms pipeline did not support > > > cursor > > > planes. This has long been resolved: the simple-kms pipeline is gone and > > > hyperv_drm runs on the regular DRM framework. Unless there's anything > > > special with the Hyper-V protocol, cursor-plane support should be do-able > > > in > > > a single patch. [^1] > > > > > I actually have been working on cursor plane support for hyperv-drm. > > I'll post a patch soon. > > Awesome! Even if it doesn't fix the reported bug, it is still an improvement > for everyone. > > To fix the bug, you *might* have to implement atomic_async_update. [1] It > allows legacy cursor updates to jump ahead of the commits and change the > cursor without vblank synchronization. It's a little-used feature and > semi-deprecated, but maybe necessary in case. (Make it a separate patch, > I'd say.) There's existing support in other drivers to see how it works. > > [1] > https://elixir.bootlin.com/linux/v7.3/source/include/drm/drm_modeset_helper_vtables.h#L1406 >
>From my testing it seems that the cursor plane support on it's own is sufficient to deal with the reported issue. So, I'll hold off on this for now. Hamza > Best regards > Thomas > > > > > Hamza > > > > > Best regards > > > Thomas > > > > > > [^1] See > > > https://elixir.bootlin.com/linux/v7.2.11/source/drivers/gpu/drm/ast/ast_cursor.c > > > for an example of how this looks. Most of it is hardware-related, but > > > hyperv > > > would likely be similar in concept. > > > > > > > > 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]/ > > > -- > > > -- > > > Thomas Zimmermann > > > Graphics Driver Developer > > > SUSE Software Solutions Germany GmbH > > > Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com > > > GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri, (HRB 36809, AG Nürnberg) > > > > > > > > -- > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com > GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri, (HRB 36809, AG Nürnberg) >
