From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: tile property contents Date: Tue, 14 Oct 2014 13:40:12 +0200 Message-ID: <20141014114011.GB5057@ulmo> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1781263613==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xorg-devel-bounces-go0+a7rfsptAfugRpC6u6w@public.gmane.org Sender: "xorg-devel" To: Dave Airlie Cc: "X.Org Devel List" , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============1781263613== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 14, 2014 at 01:23:22PM +1000, Dave Airlie wrote: > Hi, >=20 > 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. >=20 > 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, >=20 > Currently I've ascii encoded the property into a blob, >=20 > :::::::= : >=20 > I'm thinking of dropping the version field and just exposing TILE2 > property if we need it later to add more values, >=20 > 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. >=20 > 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. >=20 > 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. Also exporting the details about tiling presumes that each of the tiles can work pretty much independently, too. That's not necessarily the case for dual DSI. For a symmetric left-right split configuration this may be somewhat true, at least for one of the halves. The second half can't operate standalone. For an odd-even split I don't think either half can be made to work standalone. I'm also not sure how left-right split configurations work in video mode. I can imagine that both are really needed for the panel to properly sync, since only the right half gets the HBLANK and VBLANK signals. 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. Thierry --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUPQubAAoJEN0jrNd/PrOh/z8P/juxgUPED+5g++eWyJdtqNAh 15YPpstCpxhqZp7IM4BCpyEwbqrit49+a8RC0ztpap1eFkXLpvFSIJ5y1W0ysCft PHXih7k2K3j493zk7Yb9igKI3uLEukWzepdRg99km6xtPDQ7/06DueMTjtIGznhY EVdjLKMp+YNQNPVpTd1teVevVqYjPIANn6wuRBacA8n87j5DISVpqHhz+JXjheD3 CZbQ8GBJrUaB0zceu9uezZvjyNwQHWZfkdzNWFLDgnjf3hVt3KhZrzNYtY1EwRVP tzThOEDSPGa2Ji7LsA8GstQuL203icIQOPkST/9WwbxrXK+sP62W5G7LL9/w9Wpz oCRFR3Y3r+UgpU8ABfeoM2wR/IUQZcuYpPv1FpvCtTKb6UX0O3/c9h75JlQYPuCz 4RbcFnCH/8RKdXuW7wjrYdzRMsS8c3fLwZ5rrZpGQbX5Sw3zgj/1QG558PyY45ap y8MRAcm+qzolN9zA+MIVGkTxQCBDI9C4CXnNur2vUffFewaI+OQpYZ4Xc1GUWBvT TKl0YU4atGWvudeSNgCCTYcyIW/oxQ6XqBAsckwnGh5k4GdoaiLa6fwrIFk8nw1C U8RaXalhNZC8vYZa4KN+hz5kcEViUjLm0Io6Es4yFD7nRiDZ5u5SK84maTawx/rL v57tmj5hbwWlqoutrcW6 =/FTs -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- --===============1781263613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel --===============1781263613==--