http://bugs.freedesktop.org/show_bug.cgi?id=9200
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment #
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
>>
> Dave,
> I thought we agreed at the XDS to remove the libdrm list helpers, and
> let the drivers themselves take care of this?
> However before that's done, i915 needs a Superioctl, so we don't break
> that driver.
>
Just confirming that's what we suggested :-), I have a i915 superioctl I
nee
Dave Airlie wrote:
>
> I'm just looking at the list handling code in the TTM for libdrm,
> and I really don't think we can just leave it as-is but making it
> generic also doesn't look that easy (it would at least require adding
> destructor paths for free list object contents)
>
> Thomas, any id
Dave Airlie wrote:
> On 9/17/07, Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
>> I've been thinking about this a little more and wonder if we can get
>> away with slightly relaxed semantics compared to NO_MOVE in some cases
>> at least.
>>
>> In the current SWZ branch, we're pre-validating one or
