As per luc's "suggestion" in Novell bug.

This may generate warnings on 64-bit until we get rid of CARD32

Luc Verhaegen authored 17 years ago and Dave Airlie committed 17 years ago

Also sanitise blanking and DPMS functions

Fixes from Novell Bug 264720, and fd.o 10772

- ati.man
  . add references to radeon and r128 manpages in SEE ALSO
    (Xavier Bestel in Debian bug #386001).
  . remove the manpage suffix from atimisc reference in the text
    since there is no such manpage for now.
- radeon.man
  . typo in "specifying" (reported by A. Costa in Debian bug #432059).
  . replace a non-ascii character with the corresponding groff escape
    sequence so that it works whatever the locale (Julien Cristau).

fixes bug 5832

fixes bug 11054

This prevents modes from getting rejected due to the uninitialized maxPixClock
value.

Fixes http://bugs.freedesktop.org/show_bug.cgi?id=9816 .

spotted by Stefan Buehler

- reorder RADEONDRISetVBlankInterrupt() and RADEONDRIResume()
- see bug 11287

last mode of CRT2pScrn. See bug 11278.

- fixes bug 11238

- fixes bug 3483

Hardcode the values from a working fglrx run, this works for me now

I've no idea what it might do for anyone else

I've no idea why or what this does.

Don't needlessly turn the HW cursor on/off in RADEONLoadCursor*().

Besides cleaning up the code, this semms to avoid some HW cursor related 3D
lockups, see https://bugs.freedesktop.org/show_bug.cgi?id=10815 . My best
guess is that this is because the engine is now always idled before touching
the CRTC registers.

It can be enabled at runtime by increasing the log verbosity level.

Also change the prefix from (**) to (II) to make grepping the log file for
defaults overridden by xorg.conf more useful again.

Turn some MC related debugging output into normal informational output as it's
useful for recognizing corner cases that can cause stability issues.

- logic in RADEONUnblank() was wrong
- Calling RADEONSetupConnectors() on second instance screwed up the port info
- still seem to be HW cursor issues with zaphod mode

This attempts to keep it inside the 32-bit limit when multiplying things out
later in the randr tree.

Let me know if I screwed this up..

Dave Airlie authored 17 years ago and Dave Airlie committed 17 years ago

I noticed fglrx has DDC for the panel in the rs480 laptop, however radeon
didn't pick it up, so I valgrinded fglrx and spotted 0x1a0/0x1a4 accesses
I actually noticed this before from the BIOS but never figured it out.

So now I get DDC from the LCD on this laptop.

I noticed fglrx has DDC for the panel in the rs480 laptop, however radeon
didn't pick it up, so I valgrinded fglrx and spotted 0x1a0/0x1a4 accesses
I actually noticed this before from the BIOS but never figured it out.

So now I get DDC from the LCD on this laptop.

Due to the hardware layout RMX ddc_mode has to be set.
If ddc_mode is set, RADEONValdiateFPModes() shouldn't be called.
Bugzilla #10620 (3).

According to Lisa Wu, this is correct regarding the VESA EEDID standard.
Bugzilla #10620 (2), original patch by Lisa Wu @ATI

Some scans used to only check every second entry, some stopped at the entry
before the last entry.
Bugzilla #10620 (1), original patch by Lisa Wu @ATI