On Die, 2011-03-22 at 09:03 -0500, Ilija Hadzic wrote:
On Tue, 22 Mar 2011, Michel [ISO-8859-1] Dnzer wrote:
I'm still against this. At this point we know with certainty that DRM_VBLANK_SECONDARY won't do what we want. In particular, if CRTC 1 is disabled, the ioctl will time out, which I thought was a significant part of your motivation for these changes.
You seemed to agree with this in Pine.GSO.4.62.1103041912320.20023@umail .
Not quite. What I said is that I want to achieve is the following behavior:
a) legacy anything (kernel or DDX), unchanged behavior from what we are seeing now b) new everything (kernel and DDX), vblanks use the right CRTC.
In the post I referenced above, you said:
[...] 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).
Which made sense then and still does now, in contrast to trying to preserve ill-defined broken behaviour.
- } else {
if (cap_value) {info->high_crtc_works = TRUE;} else {xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "Your kernel does not handle VBLANKs on CRTC>1\n");info->high_crtc_works = FALSE;Is there any point in having two different warning messages? I think 'CRTC > 1' could use spaces.
There is a point: one warning tells you that the kernel is old and you have to upgrade. The other warning tells you that the kernel is new enough (it has the GET_CAP ioctl), but for some other reason refused to handle high-crtcs (which at this time doesn't exist, but it should not be the reason to "destroy" the information).
Fair enough.
I bet the change on my desk in my office that if I had the blankspace, someone would have responded with an opposite suggestion ;-).
That's bold of you. I stand by my request.