On Wed, Feb 15, 2012 at 4:59 PM, Adam Jackson <ajax@xxxxxxxxxx> 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.
Just to be devil's advocate here.. audio settings wouldn't change
before/after as a result of modeset change (I guess). And on the
other side, if you are changing some audio setting via alsa, which
makes your previous valid mode configuration invalid, then you are
kinda screwed..
As far as other sort of properties that matter (beyond color format,
which is already an attribute of the fb), the one that immediately
comes to mind is z-order.
BR,
-R
> - ajax
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
