[RFC PATCH] drm: Add plane event
Luc Verhaegen
libv at skynet.be
Wed Apr 18 09:47:10 PDT 2012
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
> provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
> can change the framebuffer of plane but user can't know completion of
> changing the framebuffer of plane via event. If DRM_MODE_PLANE_EVENT is
> added, we can also do pageflip of a plane.
This whole discussion brings up some related topics.
* Base planes, the actual main fb, should be treated as planes and fit
in the same infrastructure. I see little point in treating these things
seperately, just different capabilities (but not always).
* How to convey plane capabilities to userspace.
The current situation is not really satisfactory.
For FBs, which currently can be assigned to either a CRTC (base plane)
or a plane, you have to crystal ball in userspace to guess what the
layout for a given colourformat for a given plane should be, and the
possible differences in layout between the different planes are not
taken into account the current FB creation handlers. Apart from colour
format for actual planes you get no information up front and, if you are
lucky, you get treated with -EINVAL at the time of setting the plane.
In Xvideo, the Xv client got to ask the X server what the actual layout
had to be for a given colour format at given dimensions. This made sure
that not yet another copy, or further swizzling was needed before the hw
could display it.
Then there is scaling, position and z-ordering, again, no information up
front, sometimes you get -EINVAL, sometimes some values are silently
altered, sometimes it just messes up.
This needs to be solved differently.
It is clear that not all information can be provided beforehand to suit
all hardware and all situations, but most of what is listed above can be
provided beforehand, part of it as plane resources, and part in a
separate FB query which provides plane, colour format and dimensions,
and which then returns sizes/offsets and pitches. That what cannot be
standardized can then still be a silent alteration or -EINVAL.
Luc Verhaegen.
More information about the dri-devel
mailing list