FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Development

 
 
LinkBack Thread Tools
 
Old 02-06-2008, 07:33 PM
Bryce Harrington
 
Default Question on multi-head Dapper->Hardy upgrades

Hi mvo,

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?

(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?)

Bryce

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-07-2008, 06:24 AM
Andreas Schildbach
 
Default Question on multi-head Dapper->Hardy upgrades

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?

Are multi-head configurations actually supported with Hardy? ("support"
as of "help by the community", not technically)

I have the feeling that Ubuntu only supports single-head atm. and if
someone wants to go multihead, he is pretty much on his own. The
"Screens and Graphics" preferences do not even technically support
multihead on Intel chipsets with Gutsy, and last I checked Hardy will
not change the situation. This means that you will have to go to
command-line to configure your second screen, although an xorg.conf is
not needed any more.

Regards,

Andreas


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-07-2008, 09:27 AM
Michael Vogt
 
Default Question on multi-head Dapper->Hardy upgrades

On Wed, Feb 06, 2008 at 12:33:15PM -0800, Bryce Harrington wrote:
> Hi mvo,
Hi Bryce,

> 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?).

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? 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. We could use
e.g. https://wiki.ubuntu.com/InteractiveUpgradeHooks for this and
install one if we detect a Xinerama setup. It would have a "Command:
xrandr-config" (or whatever tool we use to configure the display) line
so that the user just has to click to get the config tool.

> (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? 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.

Cheers,
Michael

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-07-2008, 09:44 AM
Matt Zimmerman
 
Default Question on multi-head Dapper->Hardy upgrades

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?
>
> (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?)

Is it possible to detect the common failure cases? If so, I suggest:

if xorg.conf is customised AND problematic:
display (or queue) a notification telling the user:
what we're doing about this situation
why
how they can get what they want (e.g. wiki page, config tool)
back it up
else:
leave the configuration alone

If their custom configuration is broken in some less obvious way, that's why
we have bullet-proof-x, right? We should not proactively clobber their
configuration unless we have reason to believe it won't work.

--
- mdz

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-07-2008, 06:11 PM
Bryce Harrington
 
Default Question on multi-head Dapper->Hardy upgrades

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

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 02-07-2008, 06:18 PM
Bryce Harrington
 
Default Question on multi-head Dapper->Hardy upgrades

On Thu, Feb 07, 2008 at 08:24:50AM +0100, Andreas Schildbach wrote:
> 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?
>
> Are multi-head configurations actually supported with Hardy? ("support"
> as of "help by the community", not technically)

Dual-head is supported through use of the xrandr command line tool, or
through manually specifying the xrandr layout in xorg.conf.

> I have the feeling that Ubuntu only supports single-head atm. and if
> someone wants to go multihead, he is pretty much on his own. The
> "Screens and Graphics" preferences do not even technically support
> multihead on Intel chipsets with Gutsy, and last I checked Hardy will
> not change the situation.

Actually, I'm in the process of rectifying this by implementing the
xrandr support into the Screen Resolution tool (gnome-control-center).
I'm hoping to have this ready for upload by FF, however time is very
short.

Bryce

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 

Thread Tools




All times are GMT. The time now is 02:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org