Re: System Config Tools Cleanup Project - tools to eliminate/replace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-------- Original Message --------
Subject: Re: System Config Tools Cleanup Project - tools to eliminate/replace
From: Bill Nottingham <notting@xxxxxxxxxx>
To: Development discussions related to Fedora <fedora-devel-list@xxxxxxxxxx>
Date: 03/24/2009 03:06 PM


It's a tool that generates a sane xorg.conf. If that is the goal,
I think it's a better place to start than with a large barely-maintained
graphical framework.


Unfortunately it's not a 100% guarantee to get a "sane" xorg.conf. The default for resolutions in X have been to try the maximum possible by the monitor, but this may not work well with the selected video card driver. Example: mga driver with a G450 and any size LCD monitor will not work above 800x600. I had to switch to the "vesa" driver to get a working X.

There needs to be better configuration keeping. X should first see if there is an xorg.conf. If there is one, it should see if the driver matches the currently installed card. If it does, it tries to start X. If the card and driver do not match, X should ignore the xorg.conf by default with the possiblity of a "Force" option. As for resolutions, without an xorg.conf, X should try the highest available, but fallback to a lower resolution if a user hasn't clicked on an "OK" button, etc. after a set amount of time.

All of this should be exposed to user-space so that X does not have to be run as root and the xorg.conf could be configured by GDM (KDM, etc) and/or the user via PolicyKit. This should also allow for use of GTK+ or QT for configuration widgets. The last thing a new user should see is a raw Xt window.

The "rm -f xorg.conf" policy is a good one in nature, but there will always be a need for static configuration. It seems the same dynamic configuration policy was on the minds of NetworkManager developers at the start, which has caused more trouble than good. Ajax should still continue work on making X hot-pluggable, hot-switchable, and more dynamic, but a static configuration policy should not be forgotten.

tldr;

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux