On Thu, May 31, 2012 at 03:54:03PM -0400, Alex Deucher wrote:
On Thu, May 31, 2012 at 3:44 PM, Singh, Satyeshwar satyeshwar.singh@intel.com wrote:
Does this by extension mean that stride changes should also not be allowed while page flipping?
Everything beyond a crtc base address change should require a full modeset.
That's a rather silly limitation on decent hardware, but perhaps it makes sense with the current API. My recent patch for i915 just rejected pixel format, pitch and offset changes on the driver side. The hardware can actually handle such things, except currently the driver uses pipelined flips instead of direct register banging, which imposes these limitations.
For the atomic mode setting API I don't plan to special case page flips in generic code at all. I'll leave it up to the driver to decide what operations it can perform atomically and/or asynchronously.
-----Original Message----- From: dri-devel-bounces+satyeshwar.singh=intel.com@lists.freedesktop.org [mailto:dri-devel-bounces+satyeshwar.singh=intel.com@lists.freedesktop.org] On Behalf Of Laurent Pinchart Sent: Thursday, May 31, 2012 9:26 AM To: dri-devel@lists.freedesktop.org Subject: [PATCH 1/2] drm: Don't allow page flip to change pixel format
A page flip is not a mode set, changing the frame buffer pixel format doesn't make sense and isn't handled by most drivers anyway. Disallow it.
Signed-off-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
drivers/gpu/drm/drm_crtc.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 92cea9d..0d15b56 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -3530,6 +3530,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev, goto out; }
- if (crtc->fb->pixel_format != fb->pixel_format ||
- crtc->fb->bits_per_pixel != crtc->fb->bits_per_pixel ||
- crtc->fb->depth != fb->depth) {
The bits_per_pixel and depth comparisons are pointless. I'm thinking we should perhaps just remove them from the structure, so that drivers would be forced to actually use pixel_format.
I'm not sure if all the drivers have already been fixed to actually check the requested pixel_format or not, or can you ask for example RGBA8888 and have the hardware scan it out as ARGB8888 instead.