On Tue, 2009-02-17 at 09:27 -0800, Jesse Barnes wrote: > On Tuesday, February 17, 2009 9:04 am Michel Dänzer wrote: > > On Mon, 2009-02-16 at 10:42 -0800, Jesse Barnes wrote: > > > On Sunday, February 15, 2009 11:33 pm Michel Dänzer wrote: > > > > On Fri, 2009-02-13 at 10:27 -0800, Jesse Barnes wrote: > > > > > Recall our last discussion where I outlined the cases we'd have to > > > > > deal with in the modeset ioctl if we didn't use get/put to just keep > > > > > interrupts on around the calls: > > > > > > > > But we are intending to keep them on around the calls. So the problem > > > > is that you are disabling the IRQ in between? Maybe a solution could be > > > > not to mess with the counter when disabling/enabling the IRQ. It needs > > > > to be guarded by the modeset ioctl anyway, so shouldn't that work? > > > > > > The current problem isn't a disable between modeset ioctls, it's a > > > disable followed by a counter reset of any kind (modeset ioctls or not), > > > since the "last" count we track is just done in the disable function, not > > > in the modeset ioctl. Doing in in the modeset ioctl instead may be > > > possible, but as I said there are lots of cases to deal with. > > > > Isn't the actual problem that drm_irq_uninstall() updates last_vblank? > > If it didn't (and the modeset ioctl is properly called around the > > disabling and re-enabling of the IRQ), wouldn't it just work? > > No, this happens w/o an uninstall, it's just due to wraparound being added > between the disable timer & the next drm_vblank_get.
I still don't understand the problem then; this can only happen if there actually was a wraparound, as the drm_vblank_get must happen (via the modeset ioctl) before the hardware frame counter resets for any other reason. > > > But apps can't assume that; frames *will* be lost when the monitor goes > > > off, for as long as the monitor is off. So if an app isn't actively > > > using the framecount for something it can't count on a given value. > > > Right? > > > > Again, I disagree with the notion that because something may not work > > under some (in this case exceptional) circumstances, we shouldn't try to > > make it work whenever possible. > > So DPMS is exceptional? I think it's normal. Surely it's exceptional while a 'normal' OpenGL application is running. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
