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

Re: SEUL: Text vs. X



-----BEGIN PGP SIGNED MESSAGE-----


On 15-Feb-98 jfm2@club-internet.fr wrote:
- -> 
- -> Pressing CTRL-ALT-F1 will not get you out of the loop of death but it
- -> will avoid you frying your monitor.  Until we can assume than X will

It won't even do that.  When XDM fires up it automatically switches the console
to it's VT.  So you can try to switch to another VT to stop it but it will
switch you back every time it respawns itself.  You have 2 choices.  Either
type between the flashes as I do, very hard to do, or reset and boot a rescue
flop to stop XDM from starting at boot time.  I type between flashes since I
hate the thought of possible file corruption doing a reset.

I'm beginning to wonder how many that are talking about this potential problem
have actually experienced it and understand it.

- -> work out of the box (not in a long time) putting people in XDM without
- -> having given the user the opportunity to verify than it works is not
- -> the way to go.  I really don't see what is wrong in having the user
- -> start X manually once in his life.

Getting XDM to work isn't the work of a 200 year old Mage.  It's easy.  I'm
telling you it's easy because Orn and I, the UI leaders, know how to do it.  If
you want to prove us wrong then test our methods and try to prove us wrong.

That would be the best way to make it as fool-proof as possible when you think
about it.  If we have some experienced skeptics doing all they can to make it
get screwed up and tell us how they did it we can fix that too.

The only time I've seen a problem in X is when the xdm-config file looks for a
server in the Xserver file and it's not there.  Aproblem I've seen in Debian. 
Or the wrong server is used, the right server is used but in an unsupported
mode for the card, or the mode is supported but the mode timings for the mode
aren't in the XF86Config file.  Ofcourse there is the event when a user tells
the Xserver he has a multi-sync monitor when in actuallity he has an old VGA
monitor.  The former doesn't cause the loop-o-death, it causes monitor death.

So, first off, if the user doesn't see his/her card listed as supported he just
selects a generic Xserver.  If that person has gone beyond the standard Windows
setup (VGA) he will know which resolution he was using.  We put all possible
mode timings in the initial config.  The Xservers default to 8bpp so that isn't
a problem.  The largest problem I see is a user that doesn't know the limits of
his/her monitor and sets the refresh too high for it.

We can make some educated guesses from the info gathered from the user.  The
user is warned of the possible death of their system if they input invalid
information.  Most of our target users don't know what all this really means
but they sure don't want their system fried so they aren't going to purposely
input info that is beyond the abilities of their system.  I would sooner think
that, given a choice of high res and a low res that works on about every setup,
they will choose the safe route and select the generic setting.  If they
specify a specific res, then I would assume they are doing so because they
remember that setting from Windows, or were prepared and looked everything up
in Windows before beginning their Linux experience.

So our options can be setup by using the info they provide.  We can make
assumtions acording to their resolution.  We know a VGA monitor can't display
1024x768 without blowing up.  If they specify that we know they have, at least,
a generic SVGA setup.

So in the install process we can do 2 things.  We can either force them into a
generic VGA setup for later config, or we can provide an  "expert" button and
stress that only those that know what a mode timing is and how to create one
should use expert setup, along with the standard setup which will use the least
destructive setup acording to their input.

The bottom line here is...all of you go get a VGA Xserver and setup your
config's to use a generic VGA monitor.  I'll bet that not one of you will post
an XDM/X failure on this list.  Remember, if one of you wants to show me up by
getting an old EGA monitor out of the closet, that anybody still using an EGA
monitor will know enough not to set it up as a VGA.

One more thing.  As far as installing a new card, we can always do a compare on
the video BIOS to see if the card has been changed and throw them back into a
generic VGA setup at boot time, tell them there apears to be new hardware on
the system and put them in the config process again.

- -> Windows detects problems when the user does a CTRL-ALT-DEL just after
- -> boot, in that case it enters failsafe mode.

Generic VGA is a failsafe mode, for our purposes.  Ruling out file corruption. 
On that note we can throw them into a shell menu, like pdmenu if the drive was
checked because it was not unmounted cleanly.  Selecting X from that shell will
use a timer.  If they indicate X is working properly then XDM is re-enabled and
started.

So are we fighting this fight because it's impossible or because we have some
purists that hardly ever use X to begin with and/or don't understand that the
majority of Windows users (our target) just don't want to fool with it.  They
want it to start in X so they can do what it is they want to do.  How many of
you are so annoyed by splash screens and confirmation boxes that you disable
them where possible?  That's what we would be doing by dropping them in a shell
for them to start X manually.  It's just one more step for them to go through
*every time* they want to work or play.

If they want a console system with X on it that is an entirely different setup
available and has nothing to do with this thread.



- ---
Rick Jones
rickya@siservices.net
Give your very best today.  Heaven knows it's little enough.



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBNOitCkrwMsuKKoVhAQFF7QQAqL767AM7Fzv+kk3d+FR1q6z+/PgxYtAR
kexDoJgSCmTCv9BPVB6kKsETYVd/EaQf7Ldn6WGjcCka6DdsiTla2hhgMAc4yVXT
/VJC9weZgzJWmHkB/ZYzfe7TQM45RHT+PRPVxiJhHNLQb2HMRg9u54Qa/lWkVX2j
UkF+JV801do=
=bVvy
-----END PGP SIGNATURE-----