On 2026-03-02 03:53, Michel Dänzer wrote:
> 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.
Yeah, point taken, I read the other thread too late :)
- Leo
>
>
