On 12/02/2014 07:04 PM, Dave Airlie wrote:
On 3 December 2014 at 10:01, Aaron Plattner aplattner@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'.