On Tue, 2009-02-17 at 09:47 -0800, Jesse Barnes wrote: > > Btw I don't have a problem with keeping this functionality, but we need to > fix > it (the problem above is the only one I'm aware of atm). That means: > 1) removing the last count stuff and providing a "disable timer" knob > 2) changing the wait condition to handle spurious wraparound > 3) fixing the last vblank count code in the core to handle counter resets > properly > > I don't particularly care which one we choose; I think the patch I posted to > start this thread is a bugfix anyway, and (1) would be pretty trivial too.
I don't understand the idea behind 1). I think my opinion on 2) should be abundantly clear. > Maybe you want to take a stab at (3)? I can't, since I don't understand what your problem is; it was working perfectly for me after I last debugged it in drm.git (though right now I'm using the DRM from the 2.6.28 kernel and haven't seen any problems either, but that may just be luck due to the small hardware frame counter range). > As to your example, I wasn't looking for theoretical issues, but real > apps that would depend on this behavior. I haven't played with many > video apps, so I'm not sure if what you outlined is common behavior, > or if apps typically care about much higher frequencies... Neither am I, so I'd rather not make assumptions. -- 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
