tile property contents

[Dave Airlie]

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.

>> 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.