tile property contents

[Aaron Plattner]

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