Re: [RFC] drm: atomic mode set API

[Jesse Barnes <jbarnes@virtuousgeek.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2865 bytes --]

On Thu, 16 Feb 2012 00:12:49 +0100
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Wed, Feb 15, 2012 at 05:59:45PM -0500, Adam Jackson wrote:
> > On 2/15/12 5:42 PM, Jesse Barnes wrote:
> > 
> > >+#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test it for validity */
> > >+
> > >+struct drm_mode_set_config {
> > >+	__u64 crtcs;
> > >+	__u64 crtc_fbs;
> > >+	__u64 crtc_xpos; /* array of x coords for crtcs */
> > >+	__u64 crtc_ypos; /* array of y coords for crtcs */
> > >+	__u32 count_crtcs;
> > >+
> > >+	__u64 plane_sets; /* array of set_plane structs */
> > >+
> > >+	__u32 count_planes;
> > >+
> > >+	__u64 connectors;
> > >+	__u64 connector_modes;
> > >+	__u32 count_connectors;
> > >+
> > >+	__u32 flags;
> > >+};
> > 
> > This appears to be missing some []s, but I think the intent is clear.
> > 
> > >  #define DRM_MODE_ENCODER_NONE	0
> > >  #define DRM_MODE_ENCODER_DAC	1
> > >  #define DRM_MODE_ENCODER_TMDS	2
> > >
> > >This allows you to bind a bunch of fbs to crtcs with independent
> > >positions, as well as set a bunch of planes to specific fbs and
> > >layouts.  Finally, it lets you change the connector config at the same
> > >time, with a flag to simply test a config instead of actually setting
> > >it.
> > >
> > >Any comments?  Do we also need to set gamma or other properties as part
> > >of this?  What about cursors?
> > 
> > I guess you might want to set gamma atomically, but I can't imagine
> > it being a factor in anyone's "can I do this" logic.
> > 
> > How do you pass in pixel format?  Do you just assume the existing fb
> > is already in the correct format?  That could work but it kind of
> > sucks for low-memory environments since you'd need to have enough
> > room to pre-create all the fbs.  You could still do the "tear
> > everything down first" approach to work around that, but then you'd
> > still have the possibility of having nothing lit up _and_ not being
> > able to set what was requested, and then needing to unwind in
> > userspace.
> > 
> > I'd sort of also want to see audio reflected in this (sigh), since
> > that's going to affect the bandwidth math.  DP 1.2 makes that even
> > worse.
> 
> Yeah, I think we should include any funky connector, crtc, plane
> properties (the latter don't exist yet, but I guess they will sooner or
> later) because they all might affect how many and which hw resources we
> need (I'm thinking e.g. of plane setups for hw that reuses crtc engines as
> planes, but where you can use the crtc scanout engine for something else
> if it's completely occluded or set to just scan out the black borders with
> a parameter).

So just an array of set_property structs per object as well?  That came
up at today's meeting... Seems doable.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel