On Tue, 2005-05-03 at 16:38 +0100, David Woodhouse wrote:
> On Tue, 2005-05-03 at 10:41 -0400, Jeremy Katz wrote:
> > We only parse it if the X startup fails. If the X startup _succeeds_,
> > then parsing the log, killing X, and restarting it may lead to X not
> > starting back up, which ends up being worse. But this basically sounds
> > like us not being worse off on ppc laptops than on x86 ones.
>
> Couldn't we just refrain from specifying a mode in this case, since we
> _know_ we're just pulling it out of our wossname? Or if we _must_
> specify a mode, what's wrong with the one we get from 'fbset -x'?
The problem is that adding a "if this looks like this, and this looks
like this and this looks like something else" to do a workaround like
not specifying the modes does *not* lead to the code being maintainable.
It's already bad enough, there's no need to make things worse. :-)
But, doing a hack to look at the fb mode on ppc and try that resolution
probably isn't terrible to do in anaconda [1]. I'm afraid it still
isn't going to help with some of the radeon problems, though :/
Jeremy
[1] In fact, it's not -- committed the following
Index: anaconda
===================================================================
RCS file: /usr/local/CVS/anaconda/anaconda,v
retrieving revision 1.340
diff -u -u -r1.340 anaconda
--- anaconda 3 May 2005 02:00:45 -0000 1.340
+++ anaconda 3 May 2005 15:54:51 -0000
@@ -911,6 +911,14 @@
# if no monitor probed lets guess based on runres
hsync = monitorhw.getMonitorHorizSync()
vsync = monitorhw.getMonitorVertSync()
+
+ # if we're on a pmac, try to use the fb resolution
+ if not runres_override and iutil.getPPCMachine() == "PMac":
+ fbinfo = isys.fbinfo()
+ fbres = "%sx%s" %(fbinfo[0], fbinfo[1])
+ if monitor.monitor_supports_mode(hsync, vsync, fbres):
+ runres = fbres
+
res_supported = monitor.monitor_supports_mode(hsync, vsync, runres)
# XXX: this is a bit of a hack, but there are a reasonable number of