resource: X11-auto-config, another unionfs imp, CentOS

[Jane Dogalt]

I just ran across this page, which has some good info for fedora based livecd
generator developers.  Specifically, this is a dell implementation of a fedora
based (centos-4.3 really) livecd, using squashfs+unionfs, with the following
interesting choice for X11 auto configuration-

	echo "Trying to auto configure X"
	system-config-display --noui --reconfig --set-resolution=1024x768

http://linux.dell.com/files/openmanage-contributions/omsa-45-live/OMSA-Li...

-jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Toshio Kuratomi]

On Sun, 2006-04-30 at 18:18 -0700, Jane Dogalt wrote:
>  I just ran across this page, which has some good info for fedora
> based livecd
>  generator developers.  Specifically, this is a dell implementation of a fedora
>  based (centos-4.3 really) livecd, using squashfs+unionfs, with the following
>  interesting choice for X11 auto configuration-
>   
Do we have a wiki page devoted to other Fedora LiveCD implementations
with reviews, features, impressions?  It could be nice to have a
reference that shows LiveCD X and Y have already implemented feature
Foo.  Let's see if there's anything to be learned in how they did it.

>  	echo "Trying to auto configure X"
>  	system-config-display --noui --reconfig --set-resolution=1024x768
>   
This approach has some problems (I know, it's what I've got for now :-)

1) system-config-display drags in metacity, pygtk, and other things that
aren't needed when you're developing a minimal livecd or one that uses a
different GUI environment.
2) When the monitor isn't recognized, the resolution can get kicked down
to 640x480.  (I don't remember if that's just from setting a
conservative hsync or if there's some other issues as well.)

I haven't been testing all the ideas Jeremy has been relaying recently
but getting X to configure as much of the hardware as possible when it
starts seems like a big win.

I haven't looked hard enough at the detection schemes in
system-config-display to know if the problems I'm seeing with some
monitors comes from a db that system-config-display owns or from some
auto-detection that Xorg is doing, though.  So I don't know if there
will still be some work to configure the monitors I'm working with.

-Toshio

[Chitlesh GOORAH]

>  Do we have a wiki page devoted to other Fedora LiveCD
> implementations
>  with reviews, features, impressions?  It could be nice to have a
>  reference that shows LiveCD X and Y have already implemented feature
>  Foo.  Let's see if there's anything to be learned in how they did it. 
Yes there is one :)
http://fedoraproject.org/wiki/Kadischi/UserContributions
add whatever relevant items you think might be useful to it :)

Chitlesh
--
http://clunixchit.blogspot.com

[Jeremy Katz]

On Sun, 2006-04-30 at 23:08 -0700, Toshio Kuratomi wrote:
>  On Sun, 2006-04-30 at 18:18 -0700, Jane Dogalt wrote:
>  > 	echo "Trying to auto configure X"
>  > 	system-config-display --noui --reconfig --set-resolution=1024x768
>  > 
>  This approach has some problems (I know, it's what I've got for now :-)
>  
>  1) system-config-display drags in metacity, pygtk, and other things that
>  aren't needed when you're developing a minimal livecd or one that uses a
>  different GUI environment. 
Well, I wouldn't expect a truly minimal one to have X at all ;-)  pygtk
and metacity would concern me a little less, mostly due to the fact that
if you're going to use firstboot at all, you have both and you'll be
pretty hard-pressed to really do even another GUI environment with
Fedora tools and not have pygtk.

But for the non-interactive case, it should be pretty trivial to get the
basic bits abstracted into just being in rhpxl and then a simple script
could be used to create the config instead of pulling in all of
system-config-display.  All of the guts should be in rhpxl anyway

>  2) When the monitor isn't recognized, the resolution can get
> kicked down
>  to 640x480.  (I don't remember if that's just from setting a
>  conservative hsync or if there's some other issues as well.)
>  
>  I haven't been testing all the ideas Jeremy has been relaying recently
>  but getting X to configure as much of the hardware as possible when it
>  starts seems like a big win. 
It's definitely the right long-term answer.  The question is really how
far along it we can get in the FC6 timeframe, and if we can't get "far
enough", what do we do as a stop-gap.

>  I haven't looked hard enough at the detection schemes in
>  system-config-display to know if the problems I'm seeing with some
>  monitors comes from a db that system-config-display owns or from some
>  auto-detection that Xorg is doing, though.  So I don't know if there
>  will still be some work to configure the monitors I'm working with. 
Right now, s-c-display uses kudzu to try to DDC probe to find out
ranges.  The DB is mostly just for information when monitors lie or to
make things a little bit more user-pretty.

Jeremy