On Sat, Mar 19, 2011 at 1:30 PM, Mario Kleiner <mario.kleiner@xxxxxxxxxxxxxxxx> wrote: >> >> On Fri, 18 Mar 2011, Jesse Barnes wrote: >>> >>> I like the new param check, but I'd still prefer a new ioctl to abusing >>> the old one. >>> >> >> It's not "abusing" it but extending the interface in a >> backwards-compatible manner. Introducing a new one would result in two >> ioctls that essentially do the same thing, which I don't like. > >> On Fri, 18 Mar 2011, Jesse Barnes wrote: >>> > >> Yes abusing was a strong word; I just don't like encoding crtc numbers >> in a bitfield, when we just use ints everywhere else. >> >> Not a big deal, Dave will make the final call. Thanks for doing this >> work. >> -- >> Jesse Barnes, Intel Open Source Technology Center > > Hi > > A clean solution with int's in a new ioctl() would be certainly nicer. But > if we'd define a waitvblank ioctl() v2, we should probably fix other > limitations of the old one as well. > > E.g., the kernel's vblank counter is only 32 bit. The api / oml_sync_control > extension / mesa/ x etc. expose a 64 bit vblank counter. At the moment we > work around this by masking out the upper 32 bit in the ddx, accepting some > small skipped frame glitch every couple of months of uptime when the "64 > bit" counter wraps around already at 32 bits. This is something we should > probably fix in a ioctl() v2 as well. > > Take this just as my vote for Ilja's solution as a workable stop-gap measure > for fixing an existing problem until we implement a more permanent solution > for a new ioctl(). I agree. I think this is a good stop-gap to support >2 crtcs until we design a better ioctl. Alex > > best, > -mario > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
