need help with xorg.conf
in [Debian]
|
From: Stephen Powell on 13 Mar 2010 15:00 On Sat, 13 Mar 2010 00:27:48 -0500 (EST), Mark Allums wrote: > First of all, thanks for the running commentary, it is well done. > Second, it shows that X tends to ignore stuff it finds inconvenient. > From one other post, we see that xorg.conf is optional these days, and > from a different post (from OP), we see that a somewhat obscure setting > is required if you *do* use an xorg.conf file. (Option "UseBIOS" "off" > worked.) This option is specific to the savage driver and is only needed if the monitor's resolution is not supported by the video BIOS. > This shows the tendency of Linux more and more these days to eschew the > old philosophy of using simple, user-edited configurations, and instead > try to add more and more "magic". Not sure I like this trend. I hear you. For me, I don't mind if the software is smart enough to figure some things out on its own. But I want a way to override things if the defaults are not to my liking. As I mentioned in another post, there are some things, such as HorizSync and VertRefresh, that cannot be overridden for a plug-and-play monitor. I don't like that trend at all. -- .''`. Stephen Powell <zlinuxman(a)wowway.com> : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/1278354342.18901591268510248894.JavaMail.root(a)md01.wow.synacor.com
From: John Hasler on 13 Mar 2010 15:10 Stephen Powell writes: > But the designers of X are probably more interested in preventing > damage to the monitor. It is rather unlikely that any monitor modern enough to have EDID would be damaged by incorrect synch. It would just shut down if it was sent something it couldn't deal with. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/87iq90xaye.fsf(a)thumper.dhh.gt.org
From: Stephen Powell on 13 Mar 2010 16:00 On Sat, 13 Mar 2010 14:45:13 -0500 (EST), John Hasler wrote: > Stephen Powell writes: >> But the designers of X are probably more interested in preventing >> damage to the monitor. > > It is rather unlikely that any monitor modern enough to have EDID would > be damaged by incorrect synch. It would just shut down if it was sent > something it couldn't deal with. One would hope so. But the X server does, in fact, ignore any HorizSync, VertRefresh, Option "MaxClock", and a number of other monitor configuration statements when this information is obtained from EDID data. And I don't like that. I want to be able to override things. I want it to use the EDID data if there are no corresponding explicit configuration statements. But an explicit configuration statement should always, in my opinion, be able to override any probed value. -- .''`. Stephen Powell <zlinuxman(a)wowway.com> : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/1254453288.18911201268513890614.JavaMail.root(a)md01.wow.synacor.com
From: Ron Johnson on 13 Mar 2010 16:40 On 2010-03-13 13:57, Stephen Powell wrote: [snip] > if the defaults are not to my liking. As I mentioned in another post, > there are some things, such as HorizSync and VertRefresh, that cannot > be overridden for a plug-and-play monitor. I don't like that trend at all. > Incorrect values might bzzt the monitor?? -- Ron Johnson, Jr. Jefferson LA USA "If God had wanted man to play soccer, he wouldn't have given us arms." Mike Ditka -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4B9C04D7.8050505(a)cox.net
From: Stephen Powell on 13 Mar 2010 17:00
On Sat, 13 Mar 2010 14:17:10 -0500 (EST), Stephen Powell wrote: > I did indeed do the math incorrectly! What a schoolboy mistake! > I neglected to convert from bits to bytes. But I don't understand > your version either. The correct math, by the way I have traditionally > done it, is > > 1366*768*3/1024 = 3073.5k > 1366*768*4/1024 = 4098k > > This is based on a formula obtained from "Upgrading and Repairing > PCs", Sixth Edition, by Scott Mueller, page 443. (This book is > quite dated, having been copyrighted in 1996.) > > Where did you get the stuff about three buffers? Does this have > something to do with 3D graphics acceleration? I did some more research and answered my own question. I decided to consult a much more recent version of "Upgrading and Repairing PCs". In particular, I consulted the Seventeenth Edition, which was copyrighted in 2006, ten years later than the Sixth Edition. It does indeed have to do with 3D graphics. The three buffers are the front buffer, back buffer, and Z buffer. So multiply the numbers above by 3, which is what you said. That's assuming that double buffering is used. But if triple buffering is used, multiply by 4, not 3. -- .''`. Stephen Powell <zlinuxman(a)wowway.com> : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/993838866.18918121268517038668.JavaMail.root(a)md01.wow.synacor.com |