[Intel-gfx] [PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl

Daniel Vetter daniel at ffwll.ch
Sun Mar 29 23:54:55 PDT 2015


On Fri, Mar 27, 2015 at 08:18:28AM -0700, Jesse Barnes wrote:
> On 03/27/2015 01:04 AM, Daniel Vetter wrote:
> > On Fri, Mar 27, 2015 at 08:39:56AM +0200, Jani Nikula wrote:
> >> On Thu, 26 Mar 2015, Tommi Rantala <tt.rantala at gmail.com> wrote:
> >>> Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
> >>> is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
> >>>
> >>> Signed-off-by: Tommi Rantala <tt.rantala at gmail.com>
> >>
> >> Whoa. Broken since its introduction in
> >>
> >> commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e
> >> Author: Jesse Barnes <jbarnes at virtuousgeek.org>
> >> Date:   Tue Jan 3 08:05:39 2012 -0800
> >>
> >>     drm/i915: add color key support v4
> >>
> >> Cc: stable at vger.kernel.org
> > 
> > Nope, we'll just rip it out and replace it all with the drm_noop ioctl. At
> > least I didn't find any userspace anywhere and only broken definitions.
> > Proof enough this isn't useful.
> > 
> > Even more so since that means we don't have to convert the get ioctl over
> > to atomic, yay! I'll send patches.
> 
> Can we just skip the noop part and delete it altogether?  It was only
> added speculatively and obviously never used at all...

The table is indexed, we need a dummy entry. I guess we could do a
drm_invalid_ioctl function too for these, but then whether you get an
error or not doesn't really matter for unused ioctls. Hence I've stuck
with drm_noop for all these removed ioctl (except when we need a more
tailore-made lie to keep userspace happy).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list