Re: [RFC PATCH] drm: Add plane event

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux