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. 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) > >
