On Fri, 2003-12-05 at 14:40, Michel Dänzer wrote:
> On Thu, 2003-12-04 at 23:38, Soeren Sonnenburg wrote:
> > On Thu, 2003-12-04 at 18:46, Michel Dänzer wrote:
> > > On Wed, 2003-12-03 at 07:30, Soeren Sonnenburg wrote:
[...]
> > > I think I know what you mean now; scrolling or deleting lines in vim is
> > > very slow most of the time here now, but not always. Could indeed be a
> > > scheduler problem, or either gnome-terminal (you're using that as well,
> > > right?) or the X server doing something stupid which happened to have
> >
> > no. I am using multi-gnome-terminal. I strongly dislike gnome-terminal (
> > a nice thing is that it has no probs with locales/ can use utf-8
> > though). It also happens in xterm. Scrolling speed in xterm/mgt is
> > comparable... gt is much slower...
>
> Out of curiosity, did you try gnome-terminal with an anti-aliased font?
> That would be expected to be slower.
No, as there is no obvious way to use a non anti-aliased fonts just for
the gnome-terminal...
> As it happens with several apps, my money is on the kernel scheduler. I
> wonder if it could be related to the fact that HZ is 1000 now?
I now point also in the scheduler direction, as I've tried to use the
older framebuffer while getting the same effect. However I did not use
UseFBDev true in the X config while trying that and I also noted that
the DFP was not turned off when going to sleep.
However I needed this tiny patch to get it compile:
--- drivers/video/radeonfb.c 2003-12-06 15:17:34.000000000 +0100
+++ /tmp/radeonfb.c 2003-12-07 10:43:44.000000000 +0100
@@ -842,7 +842,7 @@
if (radeon_read_OF(rinfo)) {
unsigned int tmp, Nx, M, ref_div, xclk;
- tmp = INPLL(X_MPLL_REF_FB_DIV);
+ tmp = INPLL(M_SPLL_REF_FB_DIV);
ref_div = INPLL(PPLL_REF_DIV) & 0x3ff;
Nx = (tmp & 0xff00) >> 8;
@@ -943,7 +943,7 @@
return;
}
- tmp = INREG(BIOS_4_SCRATCH);
+ tmp = INREG(RADEON_BIOS_4_SCRATCH);
printk(KERN_DEBUG "radeon_get_moninfo: bios 4 scratch = %x\n", tmp);
if (rinfo->hasCRTC2) {
Soeren.
