Bug Day 9 : Dec 10, 2003

Jef Spaleta jspaleta at princeton.edu
Wed Dec 10 14:58:47 UTC 2003


Michael Schwendt wrote:
> This one? redhat-config-xfree86 --reconfig --set-driver=vesa

> Creates a highly unstable 800x600 VESA mode on my Matrox 
> Millennium G400. Already the graphical greeter keeps crashing upon >
every 2nd server restart.

Thanks for reporting back. I deliberately posted only to -devel-list
initially in the hopes that a few technically proficient would make an
attempt at testing and find some rather obvious short-comings to the
very ill-defined testing idea, before I encourage testing in the larger
volume lists.

Can you do some testing with startx. I don't think the 'safe mode'
mharris is envisioning is going to require gdm to run for the purpose
its going to serve. But I need to poke him the eye about that
specifically. Knowing if the problem is gdm specific would help me
evaluate what any sort of 'safe mode' functionality would encompass.

So please run a vesa test again using startx from runlevel 3 and try to
get into a failsafe X session or a twm managed X session.  Maybe try to
run a few obvious redhat-config* tools that you would expect to be
useful if your X session wasn't working and X tries to restart in a
'safe mode.' 

I'm also not sure about which other --set-key=value switches might need
to be used to reconfigure for vesa testing correctly. Maybe you need to
target an 8bit colordepth modes.  I'm not sure how strict mharris's
thinking is about broken modes and blacklists. It might be he's going to
end up targeting safe mode for a specific resolution for a specific
colordepth that works with a reasonable number of cards. Or he might be
looking to be clever try to find a safe mode that makes sense for each
card. Whichever it is, trying to test as many of the modes the vesa
drivers says your card supports would be good. As much data as possible
with regard to how vesa driver performs for the hardware in use is going
to be a key step for mharris to get a feel for how far this idea can
play out. 

Please, if you can help me better define a reasonable testing
methodology/guide for this test I'd feel much more comfortable
encouraging the full userbase to run the testing via announcements in
the fedora and fedora-test lists. I think i'm going to make a Bug Day
9.1 announcement on the other lists once i get some feedback on how best
to walk people through the testing.

-jef





More information about the devel mailing list