KMS

[Michel Dänzer]

On Tue, 2009-08-25 at 07:35 -0400, James Cloos wrote: 
> 
> I get numerous, mostly single-pixel anomalies whenever creating a new
> window or moving one about.  There are a number of wrong coloured pixels
> here in my emacs window, mostly wrong shades of grey in certain sections
> of the status lines.  And server side fonts are completely fubar.
> 
> The font issue looks similar to what you would expect were one to have a
> root window a pixels wide with a stride of a+b pixels worth of ram and
> to render each line of each glyph starting b pixels worth of ram after
> the start of the previous line rather that a+b pixels worth of ram.
> 
> With the emphasis on /similar/ to.
> 
> I don't use many apps which require server-side fonts -- xpdf, xmag and
> xfd are the only ones which race to mind -- but it is still anoying.

I'm not seeing these problems, though I have a rather different setup
(Mobility RV350 with 128M of VRAM).

AGP can be unreliable, maybe try if passing radeon.test=1 on loading the
radeon DRM gives any interesting results.


> Also, now that Dave has -- it looks like -- fixed the crash dump code I
> have a server crash to debug.  I presume that, given a kernel with
> radeon kms configured, starting X with the dri2 module disabled is the
> best way to avoid kms?  (The crash in question is not glx related, so
> limiting myself to swrast when debugging it is OK.)

KMS or no KMS is a decision made when initializing the radeon DRM, not
when starting X. E.g. you can add

radeon.modeset=0

to the kernel command line, but note that this will prevent a KMS-less
kernel module from loading.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer