On Tue, 15 Nov 2011 13:42:40 +0200 Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> On Tue, Nov 15, 2011 at 12:40:43PM +1000, Ben Skeggs wrote: > > On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote: > > > Planes are a bit like half-CRTCs. They have a location and fb, but > > > don't drive outputs directly. Add support for handling them to the core > > > KMS code. > > Out of curiosity, lets say you have a *really* stupid hardware overlay > > that can't do scaling (or even, has limited scaling capabilities), > > should we provide some way to expose this to userspace? > > I think yes. In fact I'd like drm_plane to replace drm_crtc as far as > scanout is concerned. That's how a lot of embedded hardware is laid > out already, and I think it's a lot cleaner approach than what we > have currently. Stuff like borders then become a simple matter or > positioning the "CRTC plane" within the larger active video area, > and panel fitters could be exposed through drm_plane scaling. > > Se either we need to think ahead more with the GETPLANE ioctl > structure, or we could add a PLANE_CAPS ioctl later to expose > additional details about the hardware. There are going to be all sorts of device specific bits we can expose with driver ioctls too (e.g. the alpha blend with restrictions on Intel stuff). But overall, yes you can definitely support overlays w/o scalers with these interfaces. We could add a plane property to expose the scaling factors supported if that helps, otherwise you could just return -ENOSUPP for any configuration where the crtc size and source size don't match. -- Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
