brainstorming for UDS-N - Graphics

[Bryce Harrington]

On Mon, Oct 04, 2010 at 03:32:17PM -0400, James Westby wrote:
> On Mon, 4 Oct 2010 09:41:27 -0700, Bryce Harrington <bryce at canonical.com> wrote:
> > Unless someone from the community is interested in doing work in this
> > area, I don't think we need UDS discussion on this.
> 
> >From what I've observed of people trying to interact with multiple
> monitors it's usually not an X problem any more. X has improved hugely
> in this area over the last couple of years, but now userspace needs to
> catch up.

That's true.  This particular case was indeed a lacking functionality in
X.org but more and more these types of issues are either kernel driver
level issues, or some quirk in the gnome config tool.

> I think that no-one really concentrated on this in userspace before, as
> plugging in a projector wasn't likely to work flawlessly. However, now
> that it does there is plenty of polish that needs to happen. Often it
> seems that applications choose the opposite of what the user wants by
> default. For instance, OpenOffice seems to put the slides on the wrong
> output most of the time.

Interesting.  I've noticed this as well in other areas.  It seems like
sometimes someone has a good idea how monitors should be magically
arranged for a particular situation, but when they implement it they
cause that autoconfiguration to occur across a much broader range of
situations.  So we end up with gaining very clever ideas that do the
right thing 25% of the time, and precisely the opposite the other 75%.

That pattern occurred repeatedly in X.org as xrandr got implemented,
driver by driver, and then we went through it again as various display
configuration tools developed.  These days things have more or less
stabilized but I think there's probably still room to improve.  But it
sounds like this pattern is repeating in userspace as apps start to gain
multi-head awareness.

> It would be great to at least have some people who are skilled in the
> area to define the interaction that should happen, so that we can at
> least work from that and file bugs when things don't conform.

I completely agree.  Some sort of truth table that defines how we expect
the system to perform across a wide range of situations.

It'd help in understanding people's bug reports.  These days a lot of
the multi-head configuration issues are weird corner cases and it's not
often clear if what they're describing is actually something most users
would expect, vs. some weird special case.  There seem to be a lot of
weird cases with docking behaviors for instance.

Bryce