Re: tile property contents

[Andy Ritger <aritger-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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.

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

> And if this is about the initial configuration problem then we (at
> intel) are working on some way to load a dt blob as a firmware image
> which would contain the entire kms state, and which we'd apply in an
> atomic modeset at driver load. Everyone else (boot splash, X, ...)
> will then just inherit that config. That should give you even
> flicker-free screen walls if you want to ;-)

Neat :)

> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
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