On Thu, 16 Feb 2012 00:12:49 +0100
Daniel Vetter <daniel@xxxxxxxx> 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:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
