All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Ritger <aritger-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "X.Org Devel List"
	<xorg-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: tile property contents
Date: Tue, 21 Oct 2014 23:34:40 -0700	[thread overview]
Message-ID: <20141022063440.GD26807@parker.nvidia.com> (raw)
In-Reply-To: <CAPM=9tzCLM2eV2Gre_52AUcdSa0z_qqYFppfGvz75e5o9eUwFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

I assume the TILE property described below would be per-connector?

It looks like this would handle the DP MST tiled display case.

At the risk of trying to solve too much at once:

There are also configurations where users configure multiple heads to
drive power walls that they want to be treated as one logical monitor,
similar to the DP MST tiled display case.  Normally, those powerwall
configurations don't have any layout information from the monitors
themselves, and the layout is configured by the user.

Would it be appropriate for users to be able to set the TILE property
in that sort of scenario?

For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
should be expressed in pixels rather than tiles?  Sometimes, the tiles
in those powerwalls may not all have the same resolution, or may be
configured with overlap.  I suppose that would make the TILE configuration
specific to the current modetimings on each tile...

Thanks,
- Andy


On Tue, Oct 14, 2014 at 01:23:22PM +1000, 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,
> 
> The other fields:
> tileid: a group id assigned by the kernel to all tiles in the same
> 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.
> 
> 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-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

  parent reply	other threads:[~2014-10-22  6:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-14  3:23 tile property contents Dave Airlie
     [not found] ` <CAPM=9tzCLM2eV2Gre_52AUcdSa0z_qqYFppfGvz75e5o9eUwFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-14 11:40   ` Thierry Reding
2014-10-14 20:35     ` Dave Airlie
2014-10-15  8:29       ` Thierry Reding
2014-10-15 10:04         ` Daniel Stone
2014-10-15 11:07           ` Thierry Reding
2014-10-22  6:34   ` Andy Ritger [this message]
2014-10-22 21:20     ` Daniel Vetter
     [not found]       ` <CAKMK7uHE=cCfpZkSaCMmePF+M2uUGXVnY4wQ4qeEN43d8n2DGA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-22 23:03         ` Andy Ritger
2014-10-23  7:58           ` Daniel Vetter
     [not found]             ` <20141023075840.GZ26941-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2014-10-24  7:25               ` Dave Airlie
2014-10-24  7:41                 ` Daniel Vetter
2014-12-03  0:01   ` Aaron Plattner
     [not found]     ` <547E52BC.6090905-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-12-03  3:04       ` Dave Airlie
     [not found]         ` <CAPM=9txM15Fiz75UMUkK=XvoGAU4+Ya=t6P3msOzstMxF8bM2g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-03 15:41           ` Aaron Plattner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141022063440.GD26807@parker.nvidia.com \
    --to=aritger-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=xorg-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.