Question on multi-head Dapper->Hardy upgrades

[Bryce Harrington]

On Thu, Feb 07, 2008 at 11:27:34AM +0100, Michael Vogt wrote:
> On Wed, Feb 06, 2008 at 12:33:15PM -0800, Bryce Harrington wrote:
> > What is our position on supporting upgrades of users with xorg.conf's
> > that have Xinerama-based dual-head configurations to Hardy (where
> > Xinerama is now deprecated)?  Is this an upgrade path that you are
> > testing, or one we will not be supporting?  If the latter, what should
> > we communicate to users about this?
> 
> Ideally it should be possible to emulate a Xinerama setup with
> xrandr. But this is upstream land of course and if that is not done,
> then we don't have the resources to do it ourself (or is there a
> technical reason why this couldn't be done?).

Most Dapper-era Xinerama setups will have been hand-made so creating a
script to parse and upgrade them to Xrandr would not likely be something
that can be feasibly done.
 
> What will happen for users with xinerama setups if they upgrade? Will
> they just be ignored and only one monitor comes up? Or will they crash
> in some way?

X will crash and thus the system will fail to start up.  The user will
be dropped into Bulletproof-X mode.  It won't tell them that the reason
they're there is because of Xinerama.

> I think its acceptable if we come up with a single head
> only and offer a quick and simple way to active the second head again
> with a gui for Xrandr.

Alright, I think I can modify displayconfig-gtk when in BPX mode to not
offer to set up multi-head (which it would do incorrectly).  

> > (This also touches on a more general question - due to the wide
> > variances that can exist in Dapper-era xorg.conf configurations, I think
> > it may be extremely hard to assure their old xorg.conf's will upgrade
> > problem-free.  Should we set aside their Dapper xorg.conf on upgrade and
> > generate a new one that uses Xorg autodetection?)
> 
> I think doing something like this is problematic. Users will have
> configured their xorg.conf in way that are not auto-detectable, some
> may prefer a lower resolution even if their monitor supports a higher
> one. Some may have setup their input device in a special way (stuff
> like "EmulateWheel" "true", "XkbOptions"    "ctrl:nocaps", etc).
> What about cases where we have two valid drivers (ati and fglrx, nv
> and nvidia). People expect that we keep that setting.
> 
> What sort of trouble do you expect?

Not that I'm expecting trouble, but I'm worried about the amount of
configurational options that have changed between then and now.  Aside
from Xinerama I don't have tangible examples that I know will break, but
given how significantly X configuration has changed between then and
now, I'm guessing we'll spot problems.  I might be just worrying too
much, but I wanted to raise the issue just in case.

> If its only a small number of
> system, I would prefer to re-generate a xorg.conf for them instead of
> re-generating them for everyone (in failsafe X mode as a option
> maybe?). We have to make sure of course that customizing the xorg.conf
> for common options is easy enough and that our failsafe X stuff is
> working.

Okay, sounds good.  For what it's worth, only one class of problems that
can arise (crashes) are handled by BPX.  Lockups and performance issues
are also potential effects from old, incorrect xorg.conf's, yet would
not be caught by failsafe code.  But like you say, we can just ask those
users to regenerate their xorg.conf and that should solve those issues.

Bryce