KMS

[James Cloos]

>>>>> "Alex" == Alex Deucher <alexdeucher at gmail.com> writes:

Alex> Remove radeonfb; it's taking the device.  The radeon kms drm
Alex> provides an fb device.

Thanks, that did it.  I don't think I'd have thought of that....

It does work, though with quite a few bugs.

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.

All of those anomalies are perfectly repeatable, and show up in, eg,
xmag(1).  They also are not limited to the window which generates them,
and can persist after that client is quit.

    :; xfd -fn fixed

is a very good and easy test case.  It generates a large number of
persistant anolalous pixes on existing windows (including the root
window) with persist until whatever owns the window does a refresh.

Which begs the question, which bugz should these be targetted to?
ati?  drm?  The server?  The kernel?

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.)

Thanks!

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6