[PATCH 1/2] drm: Don't allow page flip to change pixel format

[Ville Syrjälä]

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 at 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 at lists.freedesktop.org [mailto:dri-devel-bounces+satyeshwar.singh=intel.com at lists.freedesktop.org] On Behalf Of Laurent Pinchart
> > Sent: Thursday, May 31, 2012 9:26 AM
> > To: dri-devel at 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 at 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.

-- 
Ville Syrjälä
Intel OTC