On Thursday, February 12, 2009 2:11 am Michel Dänzer wrote: > On Wed, 2009-02-11 at 14:29 -0800, Jesse Barnes wrote: > > Michel may want to change this a bit (make the check smaller), but I'd > > still like something like this to go in. > > Yeah, as I've explained before, if we're changing this, we might as well > go all the way and make it match the 3s timeout as closely as reasonably > possible.
Yeah, and that's fine with me. > > The current wait_vblank condition won't return if the wait sequence is > > more than 8M behind the current counter. This causes problems in the > > wraparound case, which can happen if vblank interrupts have been > > disabled by the timer (after 5s of no waiters), but then re-enabled > > after a DPMS event. > > Sounds like maybe the display driver isn't calling the modeset ioctl > properly around DPMS events? It does, but take a look at that code again. If interrupts are disabled by the timer, we'll capture the frame count. If, sometime later, they're re-enabled, we'll end up in drm_update_vblank_count. And if, between those two points, we've had a DPMS event, the frame counter will have been reset and will now be a lower value, so our drm_update_vblank_count will detect a wraparound. I think any hardware that resets its frame count will be susceptible to this problem unless we make wraparounds harmless. > > (An alternative fix might be to not account for lost frames between > > off->on periods at all, removing the drm_update_vblank_count code > > entirely.) > > You can do with your driver whatever you please, but please leave the > drm_update_vblank_count code for drivers that don't have these problems. Note I'm not suggesting dropping frames due to mode set activity, just frames that happen while no client is listening (subject to the 5s timeout window of course). Can you think of a case where those frames would matter? -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
