On 2/23/26 16:27, Leo Li wrote: > > Ideally, the cursor event should be delivered when hardware latches onto the > new > cursor info and starts scanning it out. The latching event fires an interrupt > that should be handled by dm_crtc_high_irq(). > > dm_pflip_high_irq() handles an interrupt specifically for when hardware > latches > onto a new fb address; I don't think it actually fires when there's a > cursor-only update. I think if we really want to do it right, we can have > another "acrtc_attach->cursor_event" just for cusror-only updates, and deliver > the event in crtc_high_irq(). > > In any case, I don't foresee any major issues with delivering the event early.
If the event having wrong sequence & timestamp values isn't considered a "major issue", we might as well not bother and just put random values in there. ;) Compositors actually make use of the timestamp for frame scheduling. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
