From: Daniel Vetter <daniel@ffwll.ch>
To: Andy Ritger <aritger@nvidia.com>
Cc: "X.Org Devel List" <xorg-devel@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: tile property contents
Date: Thu, 23 Oct 2014 09:58:40 +0200 [thread overview]
Message-ID: <20141023075840.GZ26941@phenom.ffwll.local> (raw)
In-Reply-To: <20141022230321.GH30256@parker.nvidia.com>
On Wed, Oct 22, 2014 at 04:03:21PM -0700, Andy Ritger wrote:
> On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger <aritger@nvidia.com> wrote:
> > > 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...
> >
> > Why can't users just set that mode?
>
> Sure, users can set the mode, but:
>
> * Part of what the TILE property conveys is how monitors should be grouped
> for purposes of window maximization. Users don't have a great way to
> express that today, that I'm aware of.
My understanding for why we want the TILE property is to avoid to
duplicate displayId parsing over every bit of userspace (and the fbcon
stuff in the kernel) interested in it. Imo the proper way for userspace is
to always just inherit whatever modeset config is already there.
> * Users might configure the mode they want, but then gnome-settings-daemon
> may come along later and decide it knows better than the user how things
> should be configured. One scenario where this comes up is:
> (a) user meticulously configures his power wall
> (b) user hotplugs another monitor
> I've definitely seen cases where window managers will try to be clever
> in response to a hotplug, and clobber the user's current configuration.
> If the TILE property conveyed how some set of monitors was supposed
> to be grouped, that would hopefully give window managers additional
> information, such that they would know to keep that group intact.
Well, imnsho gnome display control center is a bit too opiniated about
automatic modeset changes. If their assumption is that they always know
perfectly what the user wants upon hotplug I really don't want to work
around this in the kernel. Since for everything else than a laptop +
beamer gnome panel always pisses me off ;-)
I think gnome should just ask the user what it wants if there's more than
2 physical displays (treating a tiled 4k screen as one ofc), since there's
really no way at all to tell.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-10-23 7:58 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
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 [this message]
[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=20141023075840.GZ26941@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=aritger@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=xorg-devel@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox