On 3 December 2014 at 10:01, Aaron Plattner <aplattner@xxxxxxxxxx> wrote: > On 10/13/2014 08:23 PM, 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, >> >> >> <ver>:<tileid>:<flags>:<maxhtiles>:<maxvtiles>:<h_tile_loc>:<v_tile_loc>:<tile_w>:<tile_h> >> >> I'm thinking of dropping the version field and just exposing TILE2 >> property if we need it later to add more values, > > > Nifty. Is there a randrproto.txt spec for this planned? > Well for KMS its a kernel property and is documented there, I suppose randrproto should also contain the info. > > What format does this ID need to be in? It looks like monitors are > identified by (vendor id, product id, serial number) tuples in the DisplayID > extension block so it would make sense to just concatenate that into one > giant number as the tileid. Having to centrally manage these (in the > kernel??) seems like overkill. I don't mind, but central management is what we've done, it wasn't a lot of work, you could munge the vendor/product/serial, but maybe DisplayId won't be the only game in town in the future and I'd hate to tie things to it. >> 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. > > > I don't know whether the other flags would be useful, but one important one > is the "native resolution" field. At least one monitor I've seen fails to > work if you drive the normal EDID "preferred" timings on both tiles. I think the last two fields are copied from that, the tile w/h, I can't see any mention of a specific native res flag. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
