[mdk-re] xfree86 and PCI Mach64 adapters (This problem is Linux-specific?)

[mdk-re] xfree86 and PCI Mach64 adapters (This problem is Linux-specific?)

[Ruslan]

Hi again,
Вот , типа нашел что-то похожее на мой случай. Написано очень умно, хотя
разобраться можно. Неужели возможно, что моя (плохая) видяха просто не умеет
работать в (хорошем) линуксе, особенно с моими (кривыми) руками?
Или надо ждать (ждать, ждать) некое нове ядро (драйвер), который полюбит мою
видяху?

http://www.xfree86.org/3.3.6/ati6.html

6. Known problems and limitations
There are several known problems or limitations related to the XFree86 ATI
driver. They include:


A number of system lockups AND BLANK SCREENS have been reported when using
PCI Mach64 adapters. The great majority of these problems have been found to
be due to system aspects that are unrelated to this driver. As of this
writing, these problems can be divided into three general areas:
Improper mouse protocol specification with some recent mice. Try different
protocol specifications or another mouse.

A system conflict with APM. This problem is Linux-specific. There is a bug
in kernels 2.0.31 or earlier that prevents proper APM operation. Upgrade to
a more recent kernel or disable APM support.

When using a Mach64's accelerator CRTC, the virtual resolution must be less
than 8192 pixels wide. The VGA CRTC further limits the virtual resolution
width to less than 4096 pixels, or to less than 2048 pixels for adapters
based on 18800's (with 256kB of memory) and on Mach64 integrated
controllers. These are hardware limits that cannot be circumvented.
Virtual resolutions requiring more than 1MB of video memory (256kB in the
monochrome case) are not supported by the VGA CRTC on 88800GX and 88800CX
adapters. This is a hardware limit that cannot be circumvented.
Due to hardware limitations, doublescanned modes are not supported by the
accelerator CRTC in 88800GX, 88800CX, 264CT and 264ET adapters.
Monochrome interlaced modes are not supported on 18800-x and 28800-x when
using a virtual resolution that is 2048 pixels or wider. This is yet another
hardware limitation that cannot be circumvented.
Video memory banking does not work in monochrome and 16-colour modes on
18800 and 18800-1 adapters. This appears to be another hardware limit, but
this conclusion cannot be confirmed at this time. The driver's default
behaviour in this case is to limit video memory to 256kB.
The default mode does not work on the more recent Mach64 adapters. This
problem is caused by the driver's attempt to use an incorrect dot clock for
the mode. This will be fixed in a future release by reading the programmable
clock generator's registers to determine the actual clock used by the mode.
Most XFree86 servers assume that the video state on entry to the server is a
text mode. This assumption is known to cause problems on operating systems
which invoke the server from a graphics mode. DBCS versions of OS/2,
primarily used in Asia, are examples of such operating systems. The
solution, for now, is to somehow coerce the OS to invoke the server from a
text mode. This driver has been changed to simply assume the mode on entry
uses the adapter's VGA CRTC (in text or graphics modes). While this action
alleviates the problem somewhat, it does not completely solve it, as the
server could still be invoked from an accelerator mode. To properly fix this
problem for all XFree86 servers is a large project, and will probably not
get done anytime soon.
Video memory corruption can still occur during mode switches on 18800 and
18800-1 adapters. Symptoms of this problem include garbled fonts on return
to text mode, and various effects (snow, dashed lines, etc) on initial entry
into a graphics mode. In the first case, the workaround is to use some other
means of restoring the text font. On Linux, this can be accomplished with
the kbd or svgalib packages. In the second case, xrefresh(1) will usually
clean up the image. No solution to this problem is currently known.
There is some controversy over what the maximum allowed clock frequency
should be on 264xT and 3D Rage adapters. For now, clocks will, by default,
be limited to 135MHz, 170MHz, 200MHz or 230MHz, depending on the specific
controller. This limit can only be increased (up to a driver-calculated
absolute maximum) through the DACSpeed specification in XF86Config. Be aware
however that doing so is untested and might damage the adapter.
Except as in the previous item, clocks are limited to 80MHz on most
adapters, although many are capable of higher frequencies. This will be
fixed in a future release.
Support for the following will be added in a future release:
Mach32 accelerator's CRTC. This support is the first step towards
accelerated support for Mach32's, Mach8's, 8514/A's and other clones.
Colour depth greater than 8, where permitted by the hardware.
Mach64, Mach32, Mach8 and 8514/A Draw Engines.
Hardware cursors.
Support, through this driver, for 3D acceleration, "TV in a window" and
video capture, as implemented in some ATI adapters, is still in exploratory
stages. There is currently no framework within an XFree86 server for these
functions, although one is in development. Also, ATI has not yet released a
register-level specification for these, except under non-disclosure
agreements.



--
Best Regards,
Ruslan
St. Petersburg, Russia