Fix VRR with HW cursor enabled

[UjinT34]

planeProps(connector->crtc->cursor, ...) results in a new surface commit event and goes into a loop which breaks VRR and might hurt VFR.
This PR avoids sending cursor state on every commit unless buffer or position changed. It fixes VRR with HW cursor while it is not moving. Any movement still breaks VRR

[vaxerski]

results in a new surface commit event

what? We're in DRM here, a "surface" doesn't exist. What are you talking about?

If you don't commit the cursor plane state, I assume it's left unaltered...? Have you checked that?

[UjinT34]

"planeProps cursor -> listener_commitWindow -> damageSurface -> CDRMAtomicImpl::commit -> planeProps cursor" goes in a loop. I don't know why it works this way. planeProps(connector->crtc->cursor, ...) make HL think that a new frame should be rendered and rendering a "new" frame results in a new planeProps(connector->crtc->cursor, ...). Something similar happens with sendPointerFrame and locked cursors hyprwm/Hyprland#6877

Looks like it's left unaltered. At least the cursor stays visible and there are no artifacts present.

[vaxerski]

planeProps cursor -> listener_commitWindow

excuse me?

[UjinT34]

You send cursor position and get a _CWlSurfaceCommit which ends up in a listener_commitWindow. No idea why this happens and how to stop it from happening. At least it looks this way. Hard to debug it since something happens outside HL and AQ and triggers this unwanted _CWlSurfaceCommit.

[vaxerski]

yea like thats the question how the fuck is that related, idk if curing the symptom will help with fixing the underlying issue