Bug 74132

*** Bug 80474 has been marked as a duplicate of this bug. ***

*** Bug 80460 has been marked as a duplicate of this bug. ***

*** Bug 80522 has been marked as a duplicate of this bug. ***

*** Bug 74731 has been marked as a duplicate of this bug. ***

*** Bug 80995 has been marked as a duplicate of this bug. ***

A similar problem occurs with laptops that have docking stations. I run with a
1600x1200 CRT in the dock, but a 1024x768 LCD outside it. It would be nice if
the configuration tool could understand and deal with the different situations
without requiring manual hacking on the config file.

*** Bug 87752 has been marked as a duplicate of this bug. ***

I have recently added dualhead support to redhat-config-xfree86 because a lot of
people are running two monitor systems these days.  I'm not going to add code to
allow multiple screen definitions for single-head systems because it's just not
that common.

How does that help George's problem?

If it's not that common, why does this have so many dupes?


What's you suggestion for working around this? Many people may have a similar
problem, but not know X has a solution, let alone know how to modify the config
file to use it.

There seems to be some confusion here.  What Thomas is requesting is not
dualhead configuration, but rather multiple layout configuration using
the config file "Layout" sections.  Multihead isn't necessarily even
relevant for this option.  Imagine a single video card with one head,
a laptop, however you want to use the LCD sometimes, but when in a docking
station or whatever you want to use the CRT.  You choose which one you
want during startup (theoretically).

This is better described as "screen layouts" or "screen layout profiles".


Some comments on other comments above:

In response to "if it's not that common, why does this bug have so many dupes?",
that is easy to answer.  All of the dupes (every single one of them) is actually
asking for multihead configuration, and not what's in this bug report.  In
other words, none of the dupes are actually reporting or requesting the
same functionality as was originally requested in this bug report.  That means
this bug report doesn't really have any dupes, since the ones that are present,
indicate an alternative feature of configuring multihead/Xinerama, and that
has been implemented.


>What's you suggestion for working around this? Many people may have a similar
>problem, but not know X has a solution, let alone know how to modify the config
>file to use it.

The suggested way of working around this, is to do whatever people have done
for the last 4 or so years for the time being.  There is only so much time
in a given development cycle to implement features in the config tools, get
them debugged and fixed, get them beta tested, get more fixes in, and
stabilize the code for the distribution release.  When features are considered,
they are considered generally for the absolute largest userbase to get the
biggest bang for the buck.  I wont disagree with you that the feature would
be nice to have for many users, but I will argue that "the current total
value of many" isn't large enough.   Multihead is something that is becoming
much more widely used, and there are other important features that would
be much higher candidates to deserve engineering resource allocation to
implement.

So, my personal feeling at least, is "this is a nice idea perhaps for some
future release, but not right now".  Brent of course maintains the tool, and
has ultimate authority, as he should.  ;o)

I think perhaps that the original feature request was simply misunderstood,
as noticed from all of the incorrect duplicates.

Another note...

The commandline switch "-layout", as well as the config file "Layout" option,
documented in XF86Config manpage are what one would use in order to implement
this.  Again though, layout profiles is perhaps an advanced option for future
but isn't really justified currently.  Not to mention that this release is
feature frozen.  It'd be a good idea to openly discuss this on the #fedora-devel
channel during Fedora Core 2 development, to determine feasibility.

Fair enough. So should it be reopened?

I didn't look at the dupes.
I still think it woul be used by more people if it was more obvious. The XF86
team added it for some reason. Do you think it was just for fun? I expect the
amount of work needed to do it would not have happened had there not beena large
application. Currently, most people don't know it's there, so they don't ask for
it. If it was there, I suspect it'd get a lot of use.

Right now those of us that know about it, know enough to configure it ourselves.
But, I saw this as a big feature of XF4.0, making DRI much more useful. Video
cards have progressed a lot in 3.5 years, but at the time most had great 2D at
high depth/resolution, but 3D needed lower depths and resolutions. Without the
layout options, I wouldn't have used 3D much.

I don't really have IRC access. The fedora-devel list might be a good place too,
or your xf86 list.

I think RandR might be a solution for laptop users, but that doesn't help with
multiple depths. Guess I need a new video card so I no longer need the lower
depth/resolution. My poor Rage128 just isn't up to snuff.

>I still think it woul be used by more people if it was more obvious.

Read the XF86Config manpage, the XFree86 manpage, and it is very obvious.

> The XF86 team added it for some reason. Do you think it was just for fun?

XFree86 contains hundreds of config file options, X server commandline switches
and other items which can be used to highly customize one's X server environment
in quite varied ways.   These options were added for various reasons.  Some
are there for basic configuration, some to work around hardware bugs/glitches,
some for advanced configuration, some for highly specialized configuration,
and others for various other reasons.

The complete array of X server configuration options and commandline switches
is DEFINITELY *NOT* something we plan on adding to our GUI config tool.  The
options are there for users to use, so feel free to go ahead and use them,
for fun, or for whatever else you desire, however every single available
XFree86 config file option is not going to end up in our GUI config tool. Our
tool is intended to be a basic tool for configuration of general features
of the XFree86 X server.  We will add features over time as we deem such
features to be necessary and fit within the goals of our operating system
and config tool framework - not simply because an extremely small but
vocal group of users (or individual user) is ranting and raving about it.

We have limited time to work on stuff as I said above, and we'll spend that
time implementing stuff that gives the biggest bang for the buck.  This is
open source software however, so by all means feel free to submit a patch
to the tool that implements what you want to have in a clean manner, and 
we'll be more than happy to review it for potential inclusion in a future
release, however no guarantees are made.

In the mean time, I think both myself and Brent have clearly indicated that
this is not something that will be included in Fedora Core 1.  It may however
be up for discussion for the future.  I can't speak for Brent, but I'm not
personally interested in even _trying_ to rationally discuss something like
this with someone who's just ranting and raving until they get their way
however.  We have proper processes, policies and procedures, finite resources,
including limited man hours and time.

Feel free to suggest features for various parts of the OS, but please be
polite and do not DEMAND them.

Alternatively, Red Hat offers professional consulting services, if you are
interested in contracting to have specific work done, ncluding customized
tools and software.  Please contact our sales department to negotiate a
contract to have work done.

Another alternative is to join the Fedora Project, and either contribute
the work, or convince someone else to volunteer to do the work.

This should explain things more clearly, and provide you with alternatives.

>>I still think it woul be used by more people if it was more obvious.
>Read the XF86Config manpage, the XFree86 manpage, and it is very obvious.

To the average user of the config tool? I'm not sure they woule env know there
is and XF86Config man page.

>> The XF86 team added it for some reason. Do you think it was just for fun?

>XFree86 contains hundreds of config file options, X server commandline switches
>and other items which can be used to highly customize one's X server
>environment in quite varied ways.   These options were added for various
>reasons.

I'm just curious why it was added. Was it to be another esoteric option, or was
it expected to be a commonly used option?

I though it was ment to be common, since it listed in the RELEASE-NOTES for 4.0,
and in the XF86 config tool.


>The complete array of X server configuration options and commandline switches
>is DEFINITELY *NOT* something we plan on adding to our GUI config tool.

I agree there. I just though this one would be usefull to others if they knew
about it, at least on par with dual head support. I figure more people have
older cards like me (and need lower resoultion/depth) than have dual head
capaibility.

You and Brent disagree. Fine. Close it and never touch it.


>vocal group of users (or individual user) is ranting and raving about it.

Not meaning to rant. I was tyrying to discuss it.

> In the mean time, I think both myself and Brent have clearly indicated that
> this is not something that will be included in Fedora Core 1.  It may however

I had asked a year ago, in RHL-8. George asked 10 months ago. I didnot ask for
it to be in FC1. You suggested this might be viable in the future, So i
suggested the RFE stay open.

>Feel free to suggest features for various parts of the OS, but please be
>polite and do not DEMAND them.

I though that's what and RFE was, a REQUEST.

Other than that, I was trying to discuss the issue. Is bugzilla inappropriate
for that? I not here, where would be the correct place?

I mistakenly duped a stack of multihead RFE's against this bug, mainly because
in my bug list all I see of this bug is the Summary.

Regardless, multihead is frequently requested, so I implemented that feature. 
Having more than one screen profile per monitor is not something we frequently
get asked for.  The reality is that most users who know they need multiple
screen sections generally are not afraid of editing the configuration file by
hand.  

As Mike said, there's no way to build a config tool that presents all the
options that XFree86 provides.  Same thing with Samba.  That means that we have
to pick and choose the most commonly used features to present in the
configuration tools.  If the config tool is merely a graphical representation of
the configuration file, you may as well edit the file by hand.

Plus, the xrandr tool now allows for changing resolutions on the fly, which
addresses part of the original request (as well as George's request).  Changing
color depths on the fly is another issue, which XFree86 does not currently allow
for.

Just FYI...

Color depth changes wont occur any time soon.  I just talked to Keith and
Jim, and they agree that color depth changing is less and less important
nowadays, and that implementing it and doing so in a clean way would be
very difficult, time consuming, and require changes to every single video
driver.  The common concensus is that an emulation of color depth changing
should be sufficient for running legacy apps in the future.  That wont cover
all cases of color depth changing 100% adequately, but for the remaining
extreme corner cases out there, running multiple servers at different
depths, using Xnest, or using some other workaround is good enough.

Since the only way color depth changing on the fly is ever likely to be
implemented, is if Keith and/or Jim implements it, they more or less decide
the future of this feature consideration.  ;o)