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().
best,
-mario
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
