On 2008/01/04 17:47 (GMT-0500) Gil Weber.com apparently typed:
On Thu January 3 2008, Felix Miata wrote
On 2008/01/03 18:51 (GMT-0500) Gil Weber.com apparently typed:
So is there something fundamentally wrong between Sax2 and my motherboard that is going to prevent me from getting this video problem fixed?
Possibly.
Am I just spinning my wheels
Probably not.
and wasting your guys' time?
Wasting is probably not quite accurate.
Sorry, poor choice of words. Should have left it at spinning my wheels. :o)
I have a lengthy superceding answer to this....
Many thanks to all of you for your expertise and patience. Using your helpful suggestions I have been able to fix the problem -- at least it is significantly better than before. :o)
I finally was able to run 'sax2 -r -m 0=i810' from a command line
According to the timestamps on http://lists.opensuse.org/opensuse/ you started the thread Mon, 31 Dec 2007 16:38:18 -0500, and after an initial response from Jan Ritzerfeld, a bit less than 4 hours later, you provided additional information. To this I provided my first reponse 30 minutes later asking for more information, which you provided about 18 hours later, Tue, 1 Jan 2008 12:33:20 -0500. In reply 1 hour and 24 minutes later, Jan Ritzerfeld pointed you to the relnote page telling you to do 'sax2 -r -m 0=i810'. In reply to Jan 1 hour 16 minutes later you questioned the logic of the instruction and digressed into what might happen if it didn't work. 27 minutes later Jan responded again, including a reiteration of the propriety of 'sax2 -r -m 0=i810'. Meanwhile, roughly 2.5 hours after your Tue, 1 Jan 2008 12:33:20 -0500 post, I made my reply to it, pointing you to the same relnote link containing 'sax2 -r -m 0=i810' as Jan. Since that post up until your report 3 days 2 hours and 48 minutes later that 'sax2 -r -m 0=i810' worked there were another 16 posts in the thread, both on point and digressions, including Wed, 2 Jan 2008 18:31:18 -0500 your report of the negative consequences of running 'sax2 -r -m 0=i810' without first closing X.
(thanks, Felix for the instructions). After logging back into the GUI my rectangles are nearly perfect! The fractional amount of horizontal vs vertical difference is so slight it is easily ignored.
As comparison, prior to switching to the i810 driver I had:
1152X864 (XGA), 72X64 DPI, and 1152X768 pixels (significantly sub-optimal)
After changing drivers I am able to get:
1280X960 (QVGA), 80X79 DPI, and 1280X960 pixels (not state-of-the-art, but a major improvement).
Measuring the 1" horizontal bar on one of Felix's test screens my monitor now shows that 1" bar as 1 1/32" (as I said, a difference easily ignored). And on another of Felix's test screens the horizontal and vertical dimensions of squares are only slightly off.
So I am thrilled to have rectangles displayed as rectangles rather than as squares.
FYI, here are the outputs of some reports from the console after the driver switch:
gil@phred:~> xdpyinfo | grep resolution resolution: 80x79 dots per inch gil@phred:~> xdpyinfo | grep dimensions dimensions: 1280x960 pixels (406x309 millimeters)
Yahoo!! :o)
Also from the xorg.conf file (edited here to conserve electrons) confirming the i810 driver rather than the intel:
# /.../ # SaX generated X11 config file # Created on: 2008-01-04T10:50:12-0500. ... Section "Monitor" DisplaySize 406 305 HorizSync 29-82 Identifier "Monitor[0]" ModelName "20G" VendorName "VIEWSONIC" VertRefresh 50-90 UseModes "Modes[0]" EndSection ... Section "Device" BoardName "i845" BusID "0:2:0" Driver "i810" Identifier "Device[0]" Option "NoDDC" Option "LinearAlloc" "16384" VendorName "Intel" EndSection ... the i810 driver fixes some but not all of the issues with the upgrade to 10.3. But, hey, who's complaining?? :o)
In regards to this video problem am I just screwed using 10.3 and this motherboard and on-board video chip?
Possibly more likely if you only just installed and didn't do any online updates yet. IIRC there were important Intel-video-related updates after 10.3 release.
All of this was done after online updates.
After a brief experiment with my i845G, I'm of the opinion that 'sax2 -r -m 0=i810' has significant nonzero probability of providing you little or no improvement. Anticipating that likelihood, here's an unusual approach - try using an xorg.conf I custom built that works on my i845G.
Thanks, Felix, but I think I'll just sit back and enjoy what I now have. This was a huge learning process for me. Hard to put so much into my head in such a short time. :o)
The point of the above thread summary and timeline was to point out on behalf of the others and myself that a whole lot of time went into trying to help you. I'm sure we are all pleased that you finally got it to work, but the preferable means to that end is not backgrading to the old driver. Backgrading, the first step that was supposed to take place in troubleshooting your problem, was supposed to prove that your hardware can be made to work. Now that we know it can, the right thing to do is proceed to determine if the current new technology driver can work too, because if it can, it should work better. Also, this thread if so completed could be a reference for future Intel sufferers to be pointed to (if they can't find it on their own). So, to complete your profession of gratitude for the considerable effort that went into helping you, and for the benefit of others in the future, there is more work you should do. Back up your current 'sax2 -r -m 0=i810'-generated xorg.conf (e.g. 'cp -a /etc/X11/xorg.conf /etc/X11/xorg.conf-good-i810') file, then make a copy of http://mrmazda.no-ip.com/tmp/xorg-i845G-intel-1400x1050x092x24.conf called /etc/X11/xorg.conf, and restart X (from root virtual console: init3, then init 5). It should work better than your current one that uses the i810 driver, allowing use of all new technology features of the intel driver supported by your i845G chip. The result of the findings may dictate a Bugzilla bug (probably against sax2 and the YaST installer) be filed and fixed so that people installing 11.0 don't have the same problem as you. Before you do that, make sure to install and test the use of mc. It's an invaluable tool which will make any copy/restore processes that might be necessary as a result of the test easy for you to do from a command line environment.
But I do have one more related issue to toss out to all of you. Many of your communications described DPIs well above 90. Jan even noted that he was getting 129X126. Incredible.
DPI is a function of the combination of display size and screen resolution. 129 DPI means a rather high resolution is used on a screen that isn't particularly large. Jan might be on about a 15" or so laptop using WSXGA+ (1680x1050) to get 129/126, though that size is a little small for WSXGA+. Sony makes 11.1" WXGA (1280x800) laptops, which run about 137 DPI.
Felix suggested that to get to around 96DPI I would need to up my resolution to 1400X1050. Remember that I don't have a nice, modern video card. I am using the onboard chip.
i845G isn't particularly old compared to your Viewsonic, roughly 5 years I think. 1400x1050 predates i845G by a whole bunch of years.
Is there potential for damaging the chip or some other component in my system by pushing the video driver that hard?
Remember the above xorg.conf file, the one I want you to try that works on my i845G? It works on mine, and 1400x1050 is nothing. If you look at that file, a minor recommenting would have it running 2048x1536, which on your display would be about 135 DPI. The thing is, even though your chip should be able to do it, your display might be old enough for it to be a bad idea to try. You might at some point sooner or later try 1600x1200 (105 DPI), but without some research on what HorizSync and VertRefresh your display can actually handle, you might be best off not to try higher than the latter.
Could a similar thing happen here by raising the resolution so high? Or is it simply a matter of trying it and seeing the visual results -- that the only risk is a less pleasing screen but there is no risk of damage?
Modern monitors just go blank, usually putting up some message about out of range, if told to do what they cannot. Older stuff, probably including yours, will put a bunch of noise on the screen instead of something useful, and if left to do that too long, might possibly cause irreparable damage. If you try, and find the screen scrambled when X tries to start, you need only do Crtl-Alt-F[1-6] to switch back to a console that doesn't have that problem. Viewsonic made excellent stuff back in 1993, so I'd not be overly worried about damage. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org