On Thu, 3 Mar 2011 17:34:53 -0600 (CST) Ilija Hadzic <ihadzic@xxxxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
