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
On Sat, Mar 19, 2011 at 1:30 PM, Mario Kleiner mario.kleiner@tuebingen.mpg.de 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Mario Kleiner