|
Bugzilla – Full Text Bug Listing |
|
Description
Kenn White
2005-10-12 20:58:18 UTC
The IMHO main problem could be that the font configuration is optimized for 1280x1024 LCD displays. Beside this you should install some more fonts with the help of YaST. On the other hand you may choose an other resolution which fits better for the physical size of your LCD but not on the physical resolution, this would lead to larger fonts. Can you attach a screen shot please?
And please attach the output of
fc-list
If possible, can you also tell me which fonts you are using?
Created attachment 53988 [details]
fc-list log file
Created attachment 53989 [details]
screen shot of a blurry screen, at least when it is displayed
Created attachment 53990 [details]
hwinfo --pci --log file
Created attachment 53991 [details]
lsmod log file
I have tried several things today. 1. decreasing the resolution to 1280x1024 fixes the screen. 2. attached is a screen shot of a blurry screen, although it does not show blurry in the .png file. 3. I have attached fs-list, hwinfo and lsmod log files. Could this be a monitor or graphics card driver issue? Werner> The IMHO main problem could be that the font configuration is Werner> optimized for 1280x1024 LCD displays. I don't think the font configuration is optimized for any specific size. 1600x1200 should be just fine. If this is the preferred size of the LCD, I think you should use it, with all other sizes the LCD will either have to interpolate or leave a black border. As always with possibly X related bugs, please post your X configuration and the log file. (In reply to comment #9) > As always with possibly X related bugs, please post your X configuration and > the > log file. > Which X configuration files/log files do you need? /etc/X11/xorg.conf and /var/log/Xorg.0.log. Yes, it could be an issue of the graphics card driver. Created attachment 54111 [details]
XConfiguration
Created attachment 54112 [details]
X log file
Created attachment 54113 [details]
x configuration file.
Created attachment 54118 [details]
hwinfo --gfx --monitor
The configuration looks fine, and the framebuffer (attachment 53989 [details]) look
perfect as well.
As the monitor is attached by an analog vga cable, and 1280x1024 seems to look
fine as well, I guess the output driver of your hardware (or the ADC of the
monitor) isn't good enough to cope with the high frequencies.
One easy test: log in w/o any desktop (not KDE, not Gnome, use any other
windowmanager, e.g. window maker), and call 'xsetroot -gray'. It should fill the
background with a repeated pattern, with every other pixel being white, the
others black. If you only see a gray background, the VGA connection isn't
capable of transporting the high frequencies.
Have you tried connecting the monitor with a DVI cable? Has this happened with
an older / other distro before?
Have not connected the monitor via dvi cable. Machine does not have dvi output. The DVI cable used is DVI on monitor end and vga style on other end. The monitor and computer are attached via Avocent SwitchView. The monitor works perfectly on other machines at 1600x1200 running Windows or other OS. On the machine I am having problems with, I dual boot using same PC and Monitor to SL9.0 and SL 9.2 with perfect montor performance. It is only when dual booting to SL 10.0 that the font is messed up. I have separate partitions on the PC for each SL installed. Have not tried SL 9.3 to see how it works. Maybe it would be worth a try. I have several partitions left for other OSs. (windows is not anywhere on this PC :-) ) This is not good. We definitivly see a regression here. Could you please test the xsetroot? Also I would like to have the configuration and log file of on older SuSE Linux that works well, in order to compare. If it was SL 9.3 it would be best :-) Created attachment 54140 [details]
XF86Config from SL9.2 - 1600x1200 works on 9.2
Created attachment 54141 [details]
Xorg log file for working sl9.2
Created attachment 54142 [details]
xorg.conf from working SL92
Created attachment 54143 [details]
hwinfo --pci --monitor from working SL92
Created attachment 54144 [details]
windowmaker screen shot after 'xsetroot -gray' on SL10
Attached requested files. I installed SL9.3 on the same machine and it works great. I am attaching a few log files to compare with other versions. So, The screen works great in 1600x1200 on SL9.0, SL9.2, SL9.3 but not on SL10.0 Created attachment 54185 [details]
Xorg.0.log SL9.3 log
Created attachment 54186 [details]
xorg.conf SL9.3 log
Just to make sure: attachment #53989 [details] (the attachment itself, not application itself that is shown on this screenshot) looks ok when running 9.3 and bad when running 10.0? (In reply to comment #24) > Created an attachment (id=54144) [edit] > windowmaker screen shot after 'xsetroot -gray' on SL10 I was interested about the image on the screen, whether you can distinguish single pixels. That the screen shot (i.e. framebuffer snapshot) looks ok is pretty clear. I have two more tests for you: could you please try using the configuration file (xorg.conf) from 9.3 with 10.0, and - as a seperate test - copy the driver (/usr/X11R6/lib/modules/drivers/i810_drv.o) from 9.3 to 10.0 and try again? The ABI hasn't changed, so the old driver should work out-of-the-box. Answer to #29, yes, the screen was blurry on 10.0 but 9.3 it was ok, even though the .png file does not show it. Before trying the xorg.conf file from 9.3 on 10.0, I rebooted into sl10. The loging screen still shows blurry chars but KDE has cleared up. Not sure what happened but that is the current state. I will change the xorg.conf to see what it does to the login screen. I may then install a fresh sl10 to see if the problem re-surfaces. You missunderstood me. I wanted to you to boot into 9.3, and look at the png you took when running 10.0. Then - just for reference - boot into 10.0 and look at the same png. It's important to use the png, not the actual application. This is the only way to be exactly sure whether this is a driver or configuration problem. The .png file looks fine in both 9.3 and 10.0. In that case it cannot be an Xorg bug. On the other hand, as the snapshot is *exactly* what is displayed on the monitor, it cannot be a fonts bug either. Sorry, I'm lost. The combination you're describing is pretty much impossible to the best of my knowledge. In effect you described that using the application you get bad output on the monitor on 9.3 and good on 10.0, while viewing the snapshot of the bad output looks good on both? Mike, Stefan, any ideas? Sorry for any confusion. It was confusing to me to have my SL10 work fine this morning. Here is a test that I just performed. 1) Install a new SL10. Screen was fuzzy, could not read most of it. I took a screen shot and it looks fuzzy on the unmodified SL10. Save screen shot of firefox screen. 2) save xorg.conf and copy sl9.3 version. Restart X 3)firefox.png file from sl10 views fine. and screen is not fuzzy. So, there is something different in the xorg.conf from default sl10 and default sl9.3 Adding new attachments of firefox.png, xorg.conf.sl10,sl93 Created attachment 54377 [details]
screen shot of firefox screen when screen was fuzzy
Created attachment 54378 [details]
xorg.conf from sl10 (second install) with fuzzy screen
Created attachment 54379 [details]
xorg.conf file from 9.3 run on sl10 that made screen look ok
That's better now. So we do have a configuration issue. Differences (apart from cosmetic changes): - 16 bit color depth in 9.3, 24 bit in 10.0 - The 1600x1200 modeline - Option "CalcAlgorithm" "CheckDesktopGeometry" in 9.3 only - Option "NoDDC" in 9.3 only My personal guess is the Modeline. Please change the 1600x1200 modeline into Modeline "1600x1200" 160.83 1600 1712 1880 2160 1200 1201 1204 1241 If that doesn't help, please add Option "NoDDC" to the "Device" section. If you get a working (i.e. non-blurry) X, please attach logfiles for the working and the non-working case, so we have minimal differences in the configurations for the according logfiles. Adding Marcus, because it could be SaX related. Maybe he has other ideas as well. Changing the modeline works. Attached are the log files after making the change. Created attachment 54387 [details]
xorg.conf after modeline change
Created attachment 54388 [details]
Xorg.0.log after modeline change
This bug has been open way too long. Sorry, Kenn. Kenn, does this occure with the current SL10.1 alpha/betas? If it does, and the added Modeline helps again, can you *please* post the configuration and log files for both with and without the modeline? Without having exact differences it is close to impossible to analyse why a wrong modeline is chosen. Installed 10.1 and problem still exists, still fuzzy fonts. When I changed the modeline to: Modeline "1600x1200" 160.83 1600 1712 1880 2160 1200 1201 1204 1241 Screen was ok, not fuzzy. Created attachment 64071 [details]
10.1 installed xorg.conf
Created attachment 64072 [details]
10.1 modified xorg.conf
The log files, please, Kenn. For both configuration files. We cannot reproduce this here, so we need your input (see comment #42). Created attachment 65709 [details]
/var/log file on working sl10.1
Created attachment 65710 [details]
/var/log file on original setup not working sl10.1
You now have the log and conf files from a fresh sl10.1 install and after change made to conf to make screen readable. Wow. X isn't exactly verbose here. The bad refresh is using a 63.07Hz refresh rate, the working one a 60Hz. This difference isn't large, and there is no other appearant difference in the log files, so it cannot be frequency limit problem. Sorry for the delay, Kenn, there had been more pressing issues here. Can you please - once again - try the two different xorg.conf (working and blurry), but just start the Xserver with Xorg -logverbose 255 this time, kill it immedeately after that (Ctrl-Alt-Backspace) and attach the logfiles. Hopefully they tell us in more verbosity what's going on here. Created attachment 74551 [details]
Original xorg.conf log file from Xorg -logverbose 255
Created attachment 74552 [details]
Xorg -logverbose 255 with working xorg.conf
Hope the log files are what you want. They are not much different. Thanks. Yes, they are what I wanted. Unfortunately, they do not help much, because I do not understand why a BIOS mode is changed by using a modeline. All of this hopefully will work much better in the future, when the intel driver does not rely on the BIOS for mode setting any more. Until then we have to cope with these issues. I personally think this is a very special issue with your mainboard and monitor combination. I'll ask Alan what's happening here, but this issue really sounds strange. Right now I cannot do anything else, thus I close this issue als LATER - as we have a workaround for you ATM. I'll post here whatever Alan tells me about this issue. From discussion with Alan:
> On Mar 25, 06 20:01:02 +0000, Alan Hourihane wrote:
> > The i810 driver does use Modelines when connected to a CRT only.
>
> ??? I thought the i810 still uses the BIOS for setting up the mode, and
> cannot set a mode for which the BIOS does not have any settings? How
> does the modeline come into play here?
VESA allows modes to be set with explicit timings as long as the
resolution matches. We allow this for CRT's, but digital panels stay at
the defaults of what the BIOS sets, which is usually 60Hz.
Kenn, you seem to have a *very* odd combination of a machine with broken / strange BIOS timing information (63Hz refresh rate, god knows how the other parameters look like) and a panel that doesn't react very well on these odd timings. As this combination cannot be fixed without breaking many known to work well combinations, I can only set this to WONTFIX. You do have a workaround by specifying the Modeline yourself right now, and a future Xserver and i810 driver will hopefully select the modeline transmitted from the monitor by EDID (which would hopefully sove the issue as well). A BIOS update to versio P25 resolves this issue. Aaaaah. So the Bios was wrong (this happens oh so often with intel). Thanks for the report. |