From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: tile property contents Date: Wed, 15 Oct 2014 10:29:22 +0200 Message-ID: <20141015082921.GD12807@ulmo> References: <20141014114011.GB5057@ulmo> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0850965572==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Dave Airlie Cc: "X.Org Devel List" , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0850965572== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u65IjBhB3TIa72Vp" Content-Disposition: inline --u65IjBhB3TIa72Vp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 15, 2014 at 06:35:52AM +1000, Dave Airlie wrote: > On 14 October 2014 21:40, Thierry Reding wrote: > > On Tue, Oct 14, 2014 at 01:23:22PM +1000, Dave Airlie wrote: > >> Hi, > >> > >> So I've been hacking on mutter and the gnome pieces for tiling, and > >> I've at least fixed mutter locally so maximise windows works and the > >> heads are in the right order. > >> > >> Now I've strung all the pieces together using a single KMS property > >> that X.org propogates, and mutter picks up and propagates over dbus as > >> well, > >> > >> Currently I've ascii encoded the property into a blob, > >> > >> :::::::: > >> > >> I'm thinking of dropping the version field and just exposing TILE2 > >> property if we need it later to add more values, > >> > >> The other fields: > >> tileid: a group id assigned by the kernel to all tiles in the same > >> group - unique per group > >> flags: bit 0 : single monitor enclosure > >> maxhtiles: total number of horiz tiles > >> maxvtiles: total number of vert tiles > >> h_tile_loc: horiz location of this output in tile group > >> v_tile_loc: vert location of this output in tile group > >> tile_w: width of this tile > >> tile_h: height of this tile. > >> > >> Now we extract all of these from the DisplayID v1.3 block, and I'm > >> wondering if maybe I shouldn't just export the whole DisplayID tiling > >> info block instead, it however encodes a few other pieces of > >> information, including bezel info, and some flags specifying behaviour > >> in some cases. > >> > >> The former could be more suitable for cases where DisplayID isn't > >> available (Dual DSI panels?) but I'm worried abuot exposing too little > >> at this point making TILE useless when the next monitor comes out. > > > > I don't think this is a good fit to describe dual DSI panels in the > > first place. While one of the modes (left-right split) could probably be > > described using the above, the other mode (odd-even split) is more > > difficult. In the latter mode, one controller will provide the odd lines > > and the other controller will provide the even lines. >=20 > Okay I'm happy with dual-DSI panels that you can hide those in the > kernel, they don't seem hotpluggable, >=20 > so if you have one in your device-tree, you can probably just never > expose the second crtc/encoder in the mode groups, > and keep them for the kernel to use as slaves for the panel. For reference: on Tegra a single CRTC sends pixel data to both DSI outputs. The DSI outputs can then be programmed to take only the pixels that they need to display. In the driver that I've submitted for review a couple of days ago this is done by enslaving the second DSI output so that it doesn't expose a regular DSI connector. The first DSI output is then "augmented" to support a maximum of 8 data lanes instead of only 4 data lanes. It'd be interesting to see if some of that can be extracted into common code, but for now I've opted to handle it all in the Tegra driver since it is the only implementation of this mode at this time. > > One other thing that worries me about this is that we defer handling of > > these complex configurations to userspace. I suppose this is fine, and > > in fact the only way, if there is no knowledge about the tile layout in > > kernel space. But if we know precisely how these various tiles are > > connected, wouldn't we be better off abstracting this away within the > > kernel and expose a single connector that is the union of all the tiles? > > After all that's what the kernel is, an abstraction between hardware and > > userspace. > > >=20 > We can't do that for the MST panels, because the abstractions is too > leaky, stealing crtcs dynamically at runtime, is screwed up and > getting pageflipping across crtcs without userspace knowing is also a > large pit of fail. I see. That sounds like it can indeed not be reasonably hidden in the kernel. Or at least I wouldn't know how, so dealing with it in userspace seems like a better option. Just for my understanding, is it typical for each of these panels to be standalone (own housing, ...) or are there monitors that actually take two connectors and each of them drives a different part of the same panel? A quick search on the internet indicates that the former is more common (I haven't actually been able to find an example of the latter). Thierry --u65IjBhB3TIa72Vp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUPjBhAAoJEN0jrNd/PrOhU8EP+gJGnFc++4iHAG5PG474wGvd qJht2yQI4fVSoDHX4hgq6d5FAvqdL6XK+zK/G2VXSTQ8Q93QZqro5Cq0gkwQkhLg gGNVZXzEB6vMWgVVo9f7ZcUXnTTZ5xPQQ4lAaygCSrf5IJxFJJdUG0ofXfjto+3M 9mtZS7fFgGEvDXYAxFJb42/72vHoGxvGdxpA9RImgxLbbGqViGwIUyVBM7/UNGXk gTg6VSO9lm8BFEl4Okvl1id+HpXlZCD/VuWBvIxoMtBd2+4w8po5z76SpNiGfztG clmhH/HU/i3lpaZF8ip4TC5qjSBgh87dhZI0iTFrRCC0dDxAOSwKvHuwrIfjBMql 8AfdDVnZEuxolr3VnaZbw1hzKislyVcYTGXPI/QP84jM46XqDGcSX/iVk+SS4baV LJyhVKCfuwALxTnSXDNj6VZebm4J8Yh12ca6Py2ws+az+sD5T2E1MbPJtCtIVhX9 LQzpbvf51WTaKWh5M7BIQ4U8OvuTWYy/2MaT9ENET8WjVC2s9YbuZvzfQHzqO15z f8rc0MZshS0+F//G9zQ3sWa5nw61lzMDexU1PAMAvHXsafvhA1eq45HiNy3EADqS ZzeHuTWMDenL39EUW3v6RBkqV5kC+4H7+p7JhiwMKE7g1scvcpEHWghNZo6w3JUI Tn0UcDIET6DpMBYpYFO+ =Y/FA -----END PGP SIGNATURE----- --u65IjBhB3TIa72Vp-- --===============0850965572== 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 --===============0850965572==--