(this is a cumulative response to all comments that came in on this thread).
My opinion is that extending the existing ioctl is better than introducing the new one given that they will be doing the same thing. Also there are fewer kernel changes so it's safer (it opens fewer opportunities to screw up and it will be easier to review and vet the changes). We probably shouldn't start the new vs. not-new ioctl debate, since even those who advocate the former seem to agree that my proposal is a pragmatic one.
I agree that it is not a good idea to "spam" the old kernel with 'unsupported type value', so I'll add a hook to the DDX to check the version and not issue the ioctl at all if it is requested on a higher CRTC. I think that's better than falling back to the old style and issuing the system call on (potentially wrong) CRTC #1 because that can block the application (and I'd rather see it proceed without attempting vblank synchronization, then block).
I'll modify my patches to include the above stated check and retest when I get a little time and post them to this list. In the meantime, if anyone wants to venture into using the patches as I sent yesterday, please report the experience. On my end things seem to be working well, my specific problems are solved and it doesn't look like I broke anything, but more ppl. test, the better. That will take care of ATI DDX and general support in DRM; I presume that someone will follow up on other DDXs (I only deal with Radeon GPUs at the moment, so I am not familiar with other DDXs).
-- Ilija _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
