From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [RFC] drm: atomic mode set API Date: Wed, 15 Feb 2012 17:53:41 -0800 Message-ID: <20120215175341.643de67b@jbarnes-desktop> References: <20120215144230.648f4349@jbarnes-x220> <4F3C38E1.304@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0569969168==" Return-path: Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by gabe.freedesktop.org (Postfix) with SMTP id 50C509E890 for ; Wed, 15 Feb 2012 17:53:45 -0800 (PST) In-Reply-To: <4F3C38E1.304@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Adam Jackson Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0569969168== Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/0BV/26Scw2PxqUKUweT8z2R"; protocol="application/pgp-signature" --Sig_/0BV/26Scw2PxqUKUweT8z2R Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 15 Feb 2012 17:59:45 -0500 Adam Jackson wrote: > On 2/15/12 5:42 PM, Jesse Barnes wrote: >=20 > > +#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just te= st 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; > > +}; >=20 > This appears to be missing some []s, but I think the intent is clear. Yeah, all the u64s are arrays. > > #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? >=20 > I guess you might want to set gamma atomically, but I can't imagine it=20 > being a factor in anyone's "can I do this" logic. >=20 > How do you pass in pixel format? Do you just assume the existing fb is=20 > already in the correct format? That could work but it kind of sucks for= =20 > low-memory environments since you'd need to have enough room to=20 > pre-create all the fbs. You could still do the "tear everything down=20 > first" approach to work around that, but then you'd still have the=20 > possibility of having nothing lit up _and_ not being able to set what=20 > was requested, and then needing to unwind in userspace. Yeah, the assumption is that the fbs have already been set up. You'll need to do that anyway if you want to queue to a flip chain or whatever. I don't see an easy way of linking that in here, since to format an fb you need an underlying buffer allocated, which is where the memory issues you mentioned come in. So in that sense, it works like the other APIs in that it assumes you have an object with content and the right pixel format all ready to go. > I'd sort of also want to see audio reflected in this (sigh), since=20 > that's going to affect the bandwidth math. DP 1.2 makes that even worse. Requesting a specific audio config? Or just returning an informative error code about why the mode was rejected (e.g. you're playing 7.1 audio on this link and there's not enough bw for the config you wanted)? How to reasonably return errors from this is an open question; should we return an array of error codes to indicate all the possible issues? Or just try our best with a single dimension and hope userspace can figure things out? --=20 Jesse Barnes, Intel Open Source Technology Center --Sig_/0BV/26Scw2PxqUKUweT8z2R Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJPPGGlAAoJEIEoDkX4Qk9hfXcQAM55EqjnbR3dJ4nHpN33/M/e aZDflSSWqSNeMYieg5ym0Ud2C8OWoFx+3ajRfjmR4geNLVoq5MlwXXKjJPqsLOta yh/FCHC480CaVCZRujOu7uE7h1UK0aQWEgsHabHuKueWjyznn7ICY0pTQpTpu7NS UhxEvhKf0mA/KnsMQ2pRb+EbUtUwRinsk0KXGuVoOkMR+n04WZd4x7V0LvoI5Y1Y qg4pdpxENxOYuRupi1Dl/RUhPT4Iwb8uih5x3GXDxmweagl/driElrN9lorkxPbq kABsN4QofAOdgMxi/2i0jZPS676X1p4ibBEqxePAMys9dUt2lhofNqnM8wzlNodO LdJBtF+saRukQk69iKRvmPmvDThTeUz4tgUFMiYsP/HHG5m58pnbKdb9rGw3Pq6J wPXXsbj1wwwlNL1AGSJPU43NXj1ib+2br7vocX3oxlIhsoYBQEupgPqMYSSPMmGs emdAfHK7hV7reS7yQLQSTsjZeUX14nl6TgMo7HgBIEF9vnqyeuSR6s9K0gWlsqge Q3VF1ZJAjAm9YF5ct4WSPmRWdnXyfipObQz1nurkP41glIjOQB9IDUNIZzohoQnI URSHYNVgg9eVMUe2mwnqvhxiSmPFSD59Av8WKMzH1erlHXn5+ITdpKvG2kWDxZpz Fdd22yKs81d6uUMIHZ3O =JVuI -----END PGP SIGNATURE----- --Sig_/0BV/26Scw2PxqUKUweT8z2R-- --===============0569969168== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0569969168==--