On 12/02/2014 07:04 PM, Dave Airlie wrote: > On 3 December 2014 at 10:01, Aaron Plattner <aplattner at nvidia.com> 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.
Alright. At least for now, we can just centrally manage group IDs in our X driver until we move that stuff to the kernel. >>> 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. Oh, got it. I was confused by this because our DisplayID parsing library calls this field 'native_resolution'. -- Aaron
