[Fedora-livecd-list] Re: X autodetection/configuration

[Jeremy Katz]

On Thu, 2006-04-13 at 12:42 -0700, Jane Dogalt wrote:
> --- Jeremy Katz <katzj at redhat.com> wrote:
> > On Wed, 2006-04-12 at 13:07 -0700, Jane Dogalt wrote:
> > > Actually it's called "Xorg -configure".  That will generate an xorg.conf
> > file
> > > that matches your vga (and sometimes monitor I think) hardware.  Then you
> > do
> > > some sed or python or perl to tune things like the user preferred
> > resolution.
> > 
> > This is actually a really poor way to do things.  Frob hardware once to
> > start X, then exit, then start again?  It's a bit overkill.
> 
> I'm not exactly sure what 'frob' means, but my guess is that hardware was made
> to be frobbed.  If it was really bad, why is the -configure option there? 
> AFAIC nothing is overkill compared to what kadischi is currently using (i.e.
> zip).

Actually, there have been bugs in the past where starting X a second
time on the same piece of hardware caused things to break.
Additionally, you add a *ton* of time given how long it takes for things
to sync and monitors going in and out of sync give a very real
impression of "completely busted crap".  There's even the occasional bug
report about the _single_ sync required going from text mode to
graphical mode during the install.

>   Plus,
> > modifying of an xorg.conf is very painful.
> 
> Here's some sample code attached... (takes existing config in from pipe,
> outputs to stdout).  I'll agree it was moderately painful, but not at all
> undoable.  (note, code is 5 years old, current xorg.conf syntax might break
> it).  And please don't bother with derisions about how ugly this or perl is.  I
> merely submit this as an example.  Look at it if you like, think about it if
> you like, and use it if you like.  If not, post your own code that gets the job
> done.

And when something changes, you are doomed.  Been there, done that.  As
for other code to generate X configs, please see the code used by
anaconda.  The problem there is that we have no good way of doing
probing of "native" resolutions for things like LCDs.  Until recently,
this was the single most reliable thing to do.  It's starting to look
like a more minimal X configuration may now be able to start working.

> > Was harassing ajax some more about this yesterday, though, and we came
> > to the conclusion that if you comment out the modes line from the
> > display section and the horizontal and vertical sync lines from the
> > monitor section, X mostly auto-detects and picks the "best" that can be
> > done.  That plus xrandr could get very reasonable automagic X setups.
> 
> If that theoretical solution turns out to work better than what I've already
> done that I know already works, I'd love to integrate it into my project.
> 
> For now though, I'm more of the mindset- get something working asap, and then
> evolutionarily change it as time, research and development progress.  I don't
> know who this ajax person is, but if they are an X developer, and suggesting
> that -configure is the wrong thing, then hopefully they will either replace
> that option with the right thing, or reimplement it as the right thing.

So because the option exists, it's the right thing?  Seriously, if it
worked so great, don't you think we would have just done that long ago
instead of writing an entire stack of stuff to deal with X
configuration?

The right thing is really basically having xorg.conf die and getting
suitable infrastructure into X to handle things like hotplugging of
video devices and monitors, actual real input hotplug support (as
opposed to the current hack where we just point at /dev/input/mice and
it appears to magically work thanks to the kernel actually being
helpful), etc.  Unfortunately, there's a lot of work to get there.
Things are definitely moving in that direction, though -- the ability to
now not specify sync ranges and modes are just one step.

Jeremy