Waiting for vertical refresh on Intel 965 and 945 chips in recent git

[Xavier Bestel]

On Fri, 2007-06-08 at 16:20 +0100, Torgeir Veimo wrote:
> On 8 Jun 2007, at 12:18, Hamish Moffatt wrote:
> 
> > On Fri, Jun 08, 2007 at 08:23:05AM +0200, Michel Dänzer wrote:
> >> On Thu, 2007-06-07 at 18:00 +0100, Simon Farnsworth wrote:
> >>>
> >>> In the 7.2 release, I could use the DRM directly to wait for  
> >>> vertical
> >>> blanking, using the DRM_IOCTL_WAIT_VBLANK ioctl. The intel driver  
> >>> has
> >>> been changed to only enable the interrupt if 3D is in use, so I  
> >>> reworked
> >>> my code to use the GLX_SGI_video_sync extension to wait for VBlank.
> >>>
> >>> I am now finding that the OpenGL based wait for VBlank also fails  
> >>> if the
> >>> window I create to get an OpenGL context is fully obscured;
> >>> glXWaitVideoSyncSGI returns 5 (GLX_BAD_CONTEXT). My code  
> >>> automatically
> >>> falls back to trying the DRM method, but DRM_IOCTL_WAIT_VBLANK  
> >>> returns
> >>> 16 (EBUSY).
> >>
> >> Yes, this is because the X server DRI layer now counts DRI windows
> >> according to visibility, to allow e.g. page flipping to work with
> >> multiple windows as long as only one of them is visible. So the intel
> >> driver can't tell the difference between a window being invisible  
> >> and it
> >> not existing at all and disables the vblank interrupts.
> >
> > How is "3D in use" defined?
> >
> > MythTV uses DRM vertical blanking sync with Xv output; I wouldn't  
> > say it
> > uses 3D by any stretch of the imagination.
> 
> If the screensaver is disabled, as is often the case when a media  
> player runs full screen, can't that be a toggle to always turn on  
> vblank irqs?

Why can't vblank be enabled only when the DRM_IOCTL_WAIT_VBLANK ioctl is
called ? Is that because OpenGL hangs on to it ?

	Xav