Description of problem:

First off a bit of background. This wasn't a problem in earlier Fedora/GDM
versions, and I'm assuming this issue is caused by upstream GDM, and while it
seems to be a bug, it may actually be a "feature" (one which I need to find out
how to disable). At any rate, the problem is as follows:

GDM seems to monitor the sanity of the X server. If there are errors present
during X initialization, GDM will not load. This may not seem like a problem,
however there are several conditions where this behavior may lead to user
confusion and frustration:

1) For example when a certain X module cannot load. Especially true for
configurations that may be using the proprietary nvidia driver and if there's no
correspondence between the X driver and the kernel module (most commonly seen
when the kernel is updated and the corresponding module is missing), then in X
there's going to be a condition which will prevent the GLX module to load, as
there is no way the card could do any acceleration. However X itself still
"works". This is caught by GDM and the result is that users can't "login" (not
even to try and figure out what might have gone wrong). The usual behavior in
this situation was that whenever any GL context was opened, the X server would
crash (guess GDM tries to prevent that "crashing" itself, or rather preventing
itself from running)

2) The problem I'm experiencing. When a given device cannot be initialized. This
goes as much for video as it goes for anything else. My problem is that that I
have configured a Wacom tablet to work with my Fedora 7 workstation. However if
the tablet is not present or attached to the computer when GDM loads, GDM will
find an error in X and will not start. The error, obviously is that Xorg cannot
initialize the wacom device. This is a rather serious problem for me, as I work
at a lab where there are more PCs than tablets and we need to swap the tablets
from one machine to another (rather than anchoring the machines to the tablets
or vice versa).

Currently the Wacom drivers doesn't support proper "hotplugging" so in order to
initialize them, users at the lab are instructed to exit the session and log
back in, or if the machine is at GDM, simply restart the server with
ctrl+alt+backspace (not the most elegant solution, but hey! It works). This has
worked rather well with the farm of FC6 machines we have. I was asked to see if
we could move the lab to F7, after installing it and configuring it on my main
machine and by chance discovering that not only critical errors would trigger
the above mentioned GDM behavior, but also "other" input device errors, which
are not by any means critical, as the CorePointer and CoreKeyboard are still
present, I was rather surprised.

Version-Release number of selected component (if applicable):

gdm-2.18.3-1.fc7

How reproducible:

Always

Steps to Reproduce:
1. (mis)configure anything that might cause "harmless" (EE)s in xorg.conf
2. Switch runlevels (to 3 then 5 or booting straight into 3 then edit, then
change to 5). GDM will display an error message stating that is has hung.
  
Actual results:

GDM doesn't load.

Expected results:

GDM to load when not critical errors are encountered (i.e, anything but the
Section "Device" failing)

Additional info:

Just for completeness sake, X loads and functions just "fine" by getting into
the session from a text console, switching to runlevel 3, killing the X server
and then issuing "startx"