Re: [PATCH] drm/hyperv: add a parameter to disable the vblank timer

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

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/20260914110004.211027-1-tzimmermann@xxxxxxx/
> > > 
> > > 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/20200622110623.113546-1-drawat.floss@xxxxxxxxx/
> 
> -- 
> --
> 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)
> 
>