From: Petr V. <VAN...@vc...> - 2004-06-04 23:33:06
|
On 29 May 04 at 15:09, Jonas Meurer wrote: > > The screen generally is unreadable after one new lineprint, what makes > pagers, editors etc unusable. The screen only gets refreshed correctly, > if I change to another tty. > After working in X for some time, the problem sometimes vanishes and > comes back after some time staying on the virtual consoles (tty). Are not you using DRI in X by any chance? When mga_dri is used, it reprograms accelerator's line length, color depth, foreground and background color (and other not so important registers) every now and then - gnome clock applet is known to trigger it either once a minute or once a second (depends on seconds being displayed or not), but other apps running in your X can trigger that too. Only 100% fix is to stop using DRI, or disabling acceleration on console (fbset -accel false). Or you can just decrease likelihood of corruption by using same color depth and same resolution in both X and on the console - then usually only one line on screen gets printed with wrong color from time to time instead of massive corruption. Petr |
From: Petr V. <VAN...@vc...> - 2004-06-08 18:42:20
|
On 8 Jun 04 at 16:03, Jonas Meurer wrote: > > (depends on seconds being displayed or not), but other apps running > > in your X can trigger that too. > > oh, so i used DRI in X until now, with the XFree86 mga driver, both > enabled in kernel and XF86Config. > I use fb driver for X now, and no DRI support any longer. Let's see if > the problems stay away now. I think that it is too drastic if you switched to fbdev driver. mga driver with DRI disabled will be much faster. > > Only 100% fix is to stop using DRI, or disabling acceleration on console > > (fbset -accel false). Or you can just decrease likelihood of corruption > > by using same color depth and same resolution in both X and on the console - > > then usually only one line on screen gets printed with wrong color from > > time to time instead of massive corruption. > > yea, then my current configuration should work. Is DRI support a > recommented feature for better performance/lookout/...? DRI is mainly for 3D performance. > and what about these two matroxfb drivers in kernel 2.6.6, one for > G100/G200/G400/G450/G550, and the other only for G100/G200/G400. > > I failed to get any information about which one to use for my G400. > what's the difference of these drivers? As helptext says, if you have G100, G200 or G400, you can toss a coin. If you have ~8KB free memory, or if you plan upgrade to G450/G550, select G100-G550 driver. If you have G400, and you are ABSOLUTELY sure that you'll rebuild your kernel with G450/G550 support BEFORE plugging G450 into the box, you can select G100-G400 choice, but I recommend it only for embeded box where you do not plan any upgrade. (Main problem is that G400 and G450 use same PCI device ID while they are completely different - G400 driver will drive G450 as G400 - and so very bad things happen... hopefully your monitor switches itself off when driven with 300Hz vertical sync) Petr |
From: Jonas M. <jo...@fr...> - 2004-06-08 20:24:14
|
On 08/06/2004 Petr Vandrovec wrote: > I think that it is too drastic if you switched to fbdev driver. mga driver > with DRI disabled will be much faster. ah, good to know. so fbdev driver should only be used for old cards without good xfree86 support like vesa? > > yea, then my current configuration should work. Is DRI support a > > recommented feature for better performance/lookout/...? > > DRI is mainly for 3D performance. so i'm not able to run software with 3D usage like tuxracer ,what I didn't manage to do anyway since my system simply freezes at running tuxracer 0.61, and all these nice xmms visualisation plugins that freezed my system too a couple of times? By the way, why did they freeze the system? doesn't this happen any longer without dri support, maybe in favour of just printing an error message? > As helptext says, if you have G100, G200 or G400, you can toss a coin. If you > have ~8KB free memory, or if you plan upgrade to G450/G550, select G100-G550 > driver. If you have G400, and you are ABSOLUTELY sure that you'll rebuild > your kernel with G450/G550 support BEFORE plugging G450 into the box, > you can select G100-G400 choice, but I recommend it only for embeded box > where you do not plan any upgrade. (Main problem is that G400 and G450 > use same PCI device ID while they are completely different - G400 driver > will drive G450 as G400 - and so very bad things happen... hopefully > your monitor switches itself off when driven with 300Hz vertical sync) wow, thanks for great information! apart from all this inferesting stuff, my monitor starts to switch mode(?) or at least horizontal size, what means it sometimes starts to jump from normal view to another mode(?) or anything. anyway: the vertical size of screen stays like it was but the horizontal size of screen switchs, and thus left and right border of screen are not seen any longer but cutted by the hardware-border of my monitor. after some time of switching monitor stays in one of both view modes, but randomly jumps to and from from time to time. any idea what causes these troubles? is it more a software problem, or is my monitor broken? bye jonas |
From: Petr V. <VAN...@vc...> - 2004-06-08 21:06:25
|
On 8 Jun 04 at 22:22, Jonas Meurer wrote: > On 08/06/2004 Petr Vandrovec wrote: > > I think that it is too drastic if you switched to fbdev driver. mga driver > > with DRI disabled will be much faster. > > ah, good to know. so fbdev driver should only be used for old cards > without good xfree86 support like vesa? It usually depends how are xfree and kernel driver willing to coexist. I tried to make kernel matroxfb as permissing as possible, but reprogramming accelerator every second while some drawing operation is in progress is really too much - so you cannot use DRI with matroxfb... > > > yea, then my current configuration should work. Is DRI support a > > > recommented feature for better performance/lookout/...? > > > > DRI is mainly for 3D performance. > > so i'm not able to run software with 3D usage like tuxracer ,what I > didn't manage to do anyway since my system simply freezes at running > tuxracer 0.61, and all these nice xmms visualisation plugins that > freezed my system too a couple of times? You should have no crashes without DRI... > By the way, why did they freeze the system? doesn't this happen any > longer without dri support, maybe in favour of just printing an error > message? ... ah, I see that you found it already. They do not print any message because your system is dead. If you have computer newer than 4 years, you'll find that you also cannot power off box by simple pressing poweroff button - - you have to hold it 4 secs. Why it crashes is question for XFree people. With older XFree's they did not set up AGP properly, and did not handle IRQs from videocard right, but with XFree 4.3 I thought that all these problems were fixed. > apart from all this inferesting stuff, my monitor starts to switch > mode(?) or at least horizontal size, what means it sometimes starts to > jump from normal view to another mode(?) or anything. anyway: the > vertical size of screen stays like it was but the horizontal size of > screen switchs, and thus left and right border of screen are not seen > any longer but cutted by the hardware-border of my monitor. > > after some time of switching monitor stays in one of both view modes, > but randomly jumps to and from from time to time. Probably picture size you are using is just on edge where monitor makes decision which of its preset settings it should use. If it happens on console, try changing pixclock a bit (it is first number in 'timmings' entry in fbset output). If it happens in XFree, change dot clock in /etc/X11/XF86Config-4... Usually change by 1% in either direction is more than sufficient to get rid of this switching. Unless your monitor is dying... Petr |
From: Jonas M. <jo...@fr...> - 2004-06-11 21:03:17
|
On 08/06/2004 Petr Vandrovec wrote: > > apart from all this inferesting stuff, my monitor starts to switch > > mode(?) or at least horizontal size, what means it sometimes starts to > > jump from normal view to another mode(?) or anything. anyway: the > > vertical size of screen stays like it was but the horizontal size of > > screen switchs, and thus left and right border of screen are not seen > > any longer but cutted by the hardware-border of my monitor. > > > > after some time of switching monitor stays in one of both view modes, > > but randomly jumps to and from from time to time. > > Probably picture size you are using is just on edge where monitor makes > decision which of its preset settings it should use. If it happens on > console, try changing pixclock a bit (it is first number in 'timmings' > entry in fbset output). If it happens in XFree, change dot clock in > /etc/X11/XF86Config-4... Usually change by 1% in either direction is more > than sufficient to get rid of this switching. Unless your monitor is dying... thanks a lot, i'll try it. but how can i get the dot clock I use as default in xfree86? bye jonas |
From: Jean D. <kh...@li...> - 2004-06-12 06:31:08
|
> thanks a lot, i'll try it. but how can i get the dot clock I use as > default in xfree86? Grep /var/log/XFree86.0.log (or whatever it's named for you) for lines like: (**) RADEON(0): Default mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz (II) RADEON(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync The first value (78.80) is the dot clock, in MHz. Alternatively, you can run "xvidtune" if you have that, and read the value after "Pixel Clock (MHz)". Hope that helps, -- Jean Delvare http://khali.linux-fr.org/ |
From: Jonas M. <jo...@fr...> - 2004-06-08 14:02:59
|
On 05/06/2004 Petr Vandrovec wrote: > Are not you using DRI in X by any chance? When mga_dri is used, it > reprograms accelerator's line length, color depth, foreground and background > color (and other not so important registers) every now and then - gnome > clock applet is known to trigger it either once a minute or once a second > (depends on seconds being displayed or not), but other apps running > in your X can trigger that too. oh, so i used DRI in X until now, with the XFree86 mga driver, both enabled in kernel and XF86Config. I use fb driver for X now, and no DRI support any longer. Let's see if the problems stay away now. > Only 100% fix is to stop using DRI, or disabling acceleration on console > (fbset -accel false). Or you can just decrease likelihood of corruption > by using same color depth and same resolution in both X and on the console - > then usually only one line on screen gets printed with wrong color from > time to time instead of massive corruption. yea, then my current configuration should work. Is DRI support a recommented feature for better performance/lookout/...? and what about these two matroxfb drivers in kernel 2.6.6, one for G100/G200/G400/G450/G550, and the other only for G100/G200/G400. I failed to get any information about which one to use for my G400. what's the difference of these drivers? bye jonas |