Re: tile property contents

[Aaron Plattner <aplattner-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

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?

> The other fields:
> tileid: a group id assigned by the kernel to all tiles in the same

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.

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

> The former could be more suitable for cases where DisplayID isn't
> available (Dual DSI panels?) but I'm worried abuot exposing too little
> at this point making TILE useless when the next monitor comes out.
>
> I'm not sure any part of the stack should be extracting things and
> splitting them out, I'd like to just give the same tile property all
> the way through.
>
> Dave.
> _______________________________________________
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>


-- 
Aaron
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel