tile property contents

[Daniel Vetter]

On Fri, Oct 24, 2014 at 05:25:58PM +1000, Dave Airlie wrote:
> >> > > 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.
> 
> Andy's idea is good, I'd considered it before, the problem being how
> to expose it nicely,
> 
> not sure if you'd want persistent via /sys or dynamic setting of the
> property by user for that session, so we could do it like xrandr
> modes.
> 
> Daniel you are missing the nice case of using TILE for non-displayid
> monitors once the infrastructure is in place.
> 
> Having it so you can create user defined tile groups to allow users to
> configure arbitrary walls is a useful thing, that you can't do any
> other way.
> 
> >
> >> * 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.
> 
> Well its not just a GNOME problem either, once things like SDL respect
> tIle properrty,
> we can create arbitary tile walls that the whole stack will respect,
> instead of hacks
> like fake xinerama.

Hm yeah if we want tile walls als logical displays for full-screening and
all that then this makes indeed sense. I didn't really consider that part,
was probably thrown off by Andy's comments that some tile walls aren't
pixel aligned which would look funky for full-screen apps I guess.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch