vblank problem (and proposed fix) on crtc > 1

[Ilija Hadzic]

On Thu, 10 Mar 2011, Michel [ISO-8859-1] Dänzer wrote:

> No, userspace shouldn't call the ioctl for a disabled CRTC during normal
> operation, that would be a bug of its own.

Well, that's exactly what DDX is doing today. Try this experiment: open a 
terminal window and run glxgears in it and observer the frame rate synced 
up to your monitor. Then in another terminal window type 'xset dpms force 
off' (or go to dpms off state any other way you want). The screen goes 
blank (disabled CRTC). Wait a while and then move your mouse to exit the 
disabled state. Notice the low frame rate reported by glxgears in one 
line. That's because glxSwapBuffers was blocked while screen was in 
power-down state.

Now I don't know if this behavior is intentional (I know your opinion 
based on the above), but it looks logical to me: if the screen is off and 
GLX attempts to wait on it, it gets what it deserves. If this is the real 
intent, then kernel returning error on disabled screen would break it (the 
application would just start to "rush" through rendering at max speed and 
eat up the I/O and CPU bandwidth for something that you can't see on the 
screen). Anyway, this is a topic for a separate thread.

I tend to agree that one day maybe the error is returned for some other 
reason (where your example may have been a bad one) so I will look into 
DRM_IOCTL_GET_CAP.

>
> The difference is that there should be no bogus error message in dmesg,
> avoiding spurious bug reports.
>

That I agree and if GET_CAP ioctl is appropriate here, I'll change to 
that. There will still be an error message in the kernel at probing time, 
but hopefully a more meaningfull one. I guess the Xorg log message should 
then be something along the "you need a newer kernel" lines. Agreed ?

>> the same behavior if either component is old (DDX or kernel), rather than
>> have different behavior for different combinations of old/new.
>
> I don't see the value in conserving fundamentally broken behaviour.
>

There is even less value in introducing a wider variety of broken 
behaviors. Returning immediately, would cause the application to rush at 
full speed through buffer swaps and eat up the CPU and I/O bandwidth.
It think that there are equal number of ppl. who would argue for that as 
those who would argue for the opposite.

>
> You could probably always return 0, or previous value + 1 or whatever,
> that's no more wrong than the values from a different CRTC.
>

What I could do doesn't matter that much, because whatever I do would not 
result it fully functional system unless both the DDX and the kernel match 
in capabilities. So I go for the one that is less likely to introduce new 
bugs or unpredictable behavior.

>
> Then at the very least the claim that 'an error message will appear in
> the kernel only once at start up time' is wrong, there will actually be
> four of them on old kernels.
>

More precisely: num_crtcs - 2 times. Use word 'once' used in a liberal 
sense ;-) it doesn't happen repetatively during the normal operation.
At least, if I can use DRM_IOCTL_GET_CAP (which I still have to check),
the message will be more meaningful.