[PATCH 0/9] drm/i915: Plane rotation support
robdclark at gmail.com
Mon Sep 30 09:15:06 PDT 2013
On Mon, Sep 30, 2013 at 10:44 AM, <ville.syrjala at linux.intel.com> wrote:
> Recently some people from inside Intel have showed some interest in 180
> degree plane rotation. To avoid a huge mess, I decided that I should
> implement the feature properly.
> So I snatched the rotation property from omapdrm, and moved some of the
> code into drm_crtc.c, added a bunch of helper stuff to drm_crtc/rect
> and implemented the relevant bits in i915. I didn't touch cursor or
> primary planes at all. I'm sort of hoping we might do the drm_plane
> conversion sometime soonish and then we'd avoid adding a bunch of
> plane properties to the crtc.
fwiw, I was leaning towards introducing primary-plane's visible to
userspace after we have atomic modeset (or really, the
propertyification associated with atomic modeset).
But that should be independent of drm_plane conversion. You probably
still want to do something like what I did in omapdrm where you attach
plane properties on the crtc as well for benefit of old userspace.
> One thing I don't really like is the current way of stuffing the bit
> number into the enum_list resulting in DRM_ROTATE_FOO being just the bit
> number. I'd prefer to make DRM_ROTATE_FOO the shifted bitmask. But I'm
> not sure if changing that would cause grief to userspace, so I left it
> alone for now.
I think this shouldn't be visible to userspace. If I remember
correctly, I just did it this way to make it easier to prevent users
of bitmask property from doing the wrong thing (setting multiple bits,
overlapping bitmask values, etc).
Anyways, from a really quick look, the core and omapdrm parts look good.
The drm_rotation_simplify() might be overkill.. or at least userspace
should see what are the supported bitmask flags and not try to ask for
something that is not supported. Or am I missing something?
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
More information about the dri-devel