On 12/02/2014 07:04 PM, Dave Airlie wrote:
On 3 December 2014 at 10:01, Aaron Plattner <aplattner@xxxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
