On Thu, 3 Mar 2011 17:34:53 -0600 (CST) Ilija Hadzic ihadzic@research.bell-labs.com wrote:
The fix/improvement I propose is to extend the request.type field in drmVBlank structure with additional 5 bits that I call high_crtc (there are lots of unused bits in that field). 5 bits covers for 32 CRTCs, which seems to be the hard limit imposed by various parts of the Xorg and DDX (e.g. possible_crtcs mask in the display descriptor, and the like). If high_crtc is zero, then DRM (kernel module) looks at the primary/secondary flag and maps them to crtc 0 and 1 (backwards compatibility with older DDX or DDX for other device that does not use the new high_crtc field). If it's not zero then it means that the higher CRTC number is specified by DDX (i.e. userland is a new DDX) and vblank is waited on the specified CRTC (this is used only for crtc > 1, crtc 0 and 1, still use the old style).
Yeah, I think that should work, though another option would be to just add a new ioctl. That would make compat checking easy for new code; it could just call the new ioctl and if that returned -ENOTTY it could fall back to the old one and throw away the CRTC info or complain if the count was too high.
But you're right that when we re-wrote the code we fixed it to handle > 2 CRTCs, so it should be mostly ready for that (modulo testing, which it sounds like you're doing already).
Jesse