Re: Draining the Swamp: A Technical User's Experience

[Jim Gettys <Jim Gettys compaq com>]

> Sender: foundation-list-admin gnome org
> From: Bastien Nocera <hadess hadess net>
> Date: 05 May 2002 16:10:04 +0100
> To: rms gnu org
> Cc: Jeff Waugh <jdub perkypants org>, foundation-list gnome org
> Subject: Re: Draining the Swamp: A Technical User's Experience
> -----
> Hi,
>
> On Sat, 2002-05-04 at 04:37, Richard Stallman wrote:
> > It would sure be a nice thing to have a convenient GNOME feature to
> > change all the X server configuration options--and 200 other things
> > that users might want to configure.
>
> No, I don't agree there. What we need is to have XFree/whatever the
> programs underneath need less options, and less configuration. All the
> software underlying GNOME is going this way:

I couldn't agree more.  More options is usually worse.  Particularly if
the need for configuration could/should be avoided.  Unfortunately,
it is not entirely possible to avoid, for reasons I'll make clear below.

If there is configuration, it should be optional and only necessary
in the unusual cases, rather than required always (as the current situation).

>
> - XFree86: the best example (known to me) is the PowerMac port of
> XFree86 that integrates very well with the hardware. The kernel gets
> information off the Open Firmware (like a BIOS but much better, ask
> Sparc admins), and XFree86 gets the info off the kernel. In the end the
> same configuration file works on most hardware, with very few changes
> (the obvious being the resolution)

Unfortunately, PC hardware is much less graceful than that found
on the MacIntosh.

Modelines are thankfully becoming much less necessary on PC's, as many/most
monitors and displays now get the information back to the operating system.

For example: there are N flavors of mice, and anything sort of USB
mice do not identify themselves at all.

And while PCI/AGP hardware in theory is self-identifying, in practice,
it often isn't, and it may take an oracle (externally provided information)
to provide the X server what it needs.  And sometimes there is
no way to determine which graphics chip is which (the vendors sometimes
have shipped chips that are different with *NO* way to tell them apart
short of expermentation or maybe a label on the chip), or that there
is an unknow amount of VRAM in th board.

And then there is Font Configuration Hell....

But I do believe the right long term goal is an empty XFree86 config file
as hardware has become increasingly self identifing.

There are a number of things we can/should do to help fix this particular
set of problems, that a couple of hackers for a few months could fix:

1) The TinyX server has code that autodetects different flavors of PS/2
and serial mice.  If someone would like to port that code to the mainline
XFree86 server, that would make much (but not all) of the headaches around
having mice work properly the first time happen.  And then many people
wouldn't have to mess with the XF86Config file just to get a working
mouse...

2) FontConfig should reduce Font Configuration Hell to almost nothing.
Among other properties, it will discover new fonts that appear automatically
(the expected location will be /usr/share/fonts, I believe), so that
adding fonts to a system (even a new directory full of fonts) will no longer
require messing with a config file at all.

3) having a tool for editing the font configuration (in /etc/fonts/fonts.conf),
which is XML based using the FontConfig library would also be a help.
Someone could get this written using libxml.

4) Keith's planning to write a directive to the XF86Config file to
use FontConfig.  A highly motivated person could offload him from at least
some of this work.  This will then mean that font configuration will no
longer have to be present at all in the XF86Config file, and with 2, and
3, will reduce headaches greatly.

5) Some of the XFree86 drivers have fundamentally broken defaults that
need fixing.  For example, if you run "XFree86 -configure", it generates
a config file that in principle ought to be adaquate for that hardware.

But often the defaults are set wrong.  For example, I've encountered
XFree86 drivers that do stupid things like default to 8 bit displays
on hardware which is at least 16 bits deep.  Systematically testing
to see that the defaults are sane, and sending in patches to fix it
so that no configuration is required would help greatly.

The right long term strategy for this particular disaster is to try to
get to the point that if the hardware is sane, everything autodetects
the correct way, so no configuration is required unless you have something
unusual to do, or the hardware is broken as described.  Keith and I have
urged XFree86 to consider replacing the XF86Config file with something
XML based (prefereably usually empty) in the long term; right now,
at most there is consensus to go ahead with FontConfig, which is a
potentially great win as it is.  So that's the short term goal.

Help would greatly be appreciated on the topics above.  Unfortunately,
the XFree86 core people are so used to this mess that they are not highly
motivated on the projects above.  After all, they understand how the
silly configuration works...  But I don't think there is any problems with
volunteers helping with the above list.
                             - Jim