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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
