-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Dänzer wrote:
> On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote:
>> It seems that drivers that set their MSC routines to NULL will return
>> GL_BAD_CONTEXT from calls like glXWaitVideoSyncSGI(), and if e.g.
>> drmWaitVBlank() failed clie
On 9/26/07, Michel Dänzer <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2007-09-26 at 08:31 -0700, Jesse Barnes wrote:
> > On Wednesday, September 26, 2007 8:11:19 am Michel Dänzer wrote:
> > > On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote:
> > > > On Wednesday, September 26, 2007 12:08:13 am Mich
On Wednesday, September 26, 2007 9:39 am Michel Dänzer wrote:
> > Err yeah I was describing it backwards. The __DRIscreen hooks for
> > the MSC stuff all point to dri_util.c wrapper functions that end up
> > calling the driver hooks. However, drivers always set their hooks
> > to either NULL or t
On Wed, 2007-09-26 at 08:31 -0700, Jesse Barnes wrote:
> On Wednesday, September 26, 2007 8:11:19 am Michel Dänzer wrote:
> > On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote:
> > > On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote:
> > > > On Tue, 2007-09-25 at 13:32 -0700, Je
On Wednesday, September 26, 2007 8:11:19 am Michel Dänzer wrote:
> On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote:
> > On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote:
> > > On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote:
> > > > that moves the new fields over to the
On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote:
> On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote:
> > On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote:
> > >
> > > that moves the new fields over to the drawable private. I added a new
> > > drawable hook to implement
On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote:
> On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote:
> > On Monday, September 24, 2007 1:25 am Michel Dänzer wrote:
> > > On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote:
> > > > On Friday, September 21, 2007 2:51 am Michel
On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote:
> On Monday, September 24, 2007 1:25 am Michel Dänzer wrote:
> > On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote:
> > > On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
> > > > > - add code to Mesa so GetMSC/WaitForMSC set
> >
On Monday, September 24, 2007 1:25 am Michel Dänzer wrote:
> On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote:
> > On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
> > > > - add code to Mesa so GetMSC/WaitForMSC set
> > > > DRM_VBLANK_SECONDARY correctly
> > >
> > > One idea (with
On Monday, September 24, 2007 1:25 am Michel Dänzer wrote:
> On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote:
> > On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
> > > > - add code to Mesa so GetMSC/WaitForMSC set
> > > > DRM_VBLANK_SECONDARY correctly
> > >
> > > One idea (with
On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote:
> On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
> > > - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY
> > > correctly
> >
> > One idea (with some handwaving :) would be the common code keeping
> > around a po
On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
> > - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY
> > correctly
>
> One idea (with some handwaving :) would be the common code keeping
> around a pointer to the driver's vblank_flags variable or keeping
> track of t
On Fri, 2007-09-21 at 07:59 -0700, Jesse Barnes wrote:
> On Friday, September 21, 2007 2:51:02 am Michel Dänzer wrote:
> > > So:
> > > - use the vblank-rework tree to make per-CRTC vblank counters (as
> > > you
> > > say, this breaks some setups but will fix others)
> >
> > Out of curiosity,
On Friday, September 21, 2007 2:51:02 am Michel Dänzer wrote:
> > So:
> > - use the vblank-rework tree to make per-CRTC vblank counters (as
> > you
> > say, this breaks some setups but will fix others)
>
> Out of curiosity, what setups are you thinking of that this will fix on
> its own? Can'
On Wed, 2007-09-19 at 09:59 -0700, Jesse Barnes wrote:
> On Wednesday, September 19, 2007 3:52 am Michel Dänzer wrote:
> > On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote:
> > > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new
> > > world of dyanmically controlled outputs an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Barnes wrote:
> Both the generic DRM vblank-rework and Intel specific pipe/plane
> swapping have uncovered some vblank related problems which we discussed
> at XDS last week. Unfortunately, no matter what we do (including
> the "do nothing" o
On Wednesday, September 19, 2007 3:52 am Michel Dänzer wrote:
> On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote:
> > As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new
> > world of dyanmically controlled outputs and CRTCs (at least for
> > i915 and radeon): a client trying to
On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote:
>
> As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new world
> of dyanmically controlled outputs and CRTCs (at least for i915 and
> radeon): a client trying to sync against the second CRTC that doesn't
> pass _DRM_VBLANK_SE
On 18 Sep 2007, at 22:54, Jesse Barnes wrote:
Any other thoughts?
Please do add the option of retrieving a serial number of the vsync
irq. It is very handy when debugging video playback that suffers from
judder.
--
Torgeir Veimo
[EMAIL PROTECTED]
-
On Tuesday, September 18, 2007 3:10 pm Torgeir Veimo wrote:
> On 18 Sep 2007, at 22:54, Jesse Barnes wrote:
> > Any other thoughts?
>
> Please do add the option of retrieving a serial number of the vsync
> irq. It is very handy when debugging video playback that suffers from
> judder.
This should
Jesse Barnes wrote:
> Both the generic DRM vblank-rework and Intel specific pipe/plane
> swapping have uncovered some vblank related problems which we discussed
> at XDS last week. Unfortunately, no matter what we do (including
> the "do nothing" option), some applications will break some of th
Both the generic DRM vblank-rework and Intel specific pipe/plane
swapping have uncovered some vblank related problems which we discussed
at XDS last week. Unfortunately, no matter what we do (including
the "do nothing" option), some applications will break some of the time
in the new world ord
22 matches
Mail list logo