| Age | Commit message (Collapse) | Author |
|---|
|
- reorder RADEONDRISetVBlankInterrupt() and RADEONDRIResume()
- see bug 11287
|
|
last mode of CRT2pScrn. See bug 11278.
|
|
|
|
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
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).
|
|
If the secondary head isn't found (Monitor unplugged etc.) but MergedFB
is configured, the driver segfaults because it tries to access the mode
list private structures, which are not filled in.
|
|
Thanks to Matthew Garrett and Ubuntu for the hw loan to get this working.
Still no 3D driver support but at least you should get CP acceleration for
2D now.
|
|
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=10442 .
|
|
|
|
|
|
when IsSecondary is true, crtc1 is NULL
Noticed by Sverre Froyen.
|
|
|
|
|
|
Don't flush indirect buffer in BlockHandler; it's done in LeaveServer.
Also set the EXA engine mode to unknown only at the end.
|
|
Walk the SAREA texList and bump the age of every active object, so their owners
will consider them kicked out when they grab the HW lock next time.
|
|
This requires a drm > 1.26 to work
|
|
This option allows you to disable the DRI per card. It also
removes the "RN50Force3D" option as it is now covered by this
option. RN50 users should set this to TRUE if they want to force
the DRI on.
|
|
Allow user to force the DRI on for RN50 chips.
3D is not guaranteed to work on these chips,
however in some cases it does.
fixes bug 9802.
|
|
This might fix bug 9371
|
|
Since the reorganization of the mode setting code, the mode registers relying
on state already set (by bios) were not read, thus clearing out all bits the
driver does not touch. At the very least, this could lead to completely
nonfunctional to misbehaving dvi output (see bug 9495). Fix this by using the
SavedReg values, which also makes it more obvious that those are bits which
were not set by the driver previously, but come from register readback.
|
|
Based on the assumption that firmware should have set up the card and host
bridge appropriately for these settings, this may actually be safer, at least
for the transfer rate; leaving fast writes enabled is hopefully safe as well,
it certainly is on my sytem.
See https://bugs.freedesktop.org/show_bug.cgi?id=9284 .
|
|
It is not necessary to always emit a OUTPLL/INPLL pair when we display
a video frame. On some chips there are erratas for which the workarounds
cause a 10ms delay by those calls. This is related to #5876 though those
affected may suffer from other slowness issues too.
|
|
This unclutters RADEONPreInit() somewhat, but more importantly moves comparison
against info->ChipFamily after that's initialized.
|
|
|
|
|
|
Still not allowing any clone modes, but heading in the correct direction
I hope... there is a chance this will regress something from superpatch..
|
|
|
|
This is leading towards randr-1.2 believe me :-)
|
|
|
|
|
|
Works with 1920x1080 video on my M10.
|
|
|
|
Use the overlay scaler's predownscale capability to make videos with large
horizontal resolution work if it exceeds the scaler buffer width. Make the
scaler buffer width user-configurable since we don't know it for all chips,
and using predownscaling may otherwise reduce quality even if it wouldn't
be needed. This should fix bug #1462.
|
|
In theory the driver should be able to handle the front buffer not at VRAM 0
In practice it didn't.. this is cleanup for at least XAA parts of the driver
to allow for the frontbuffer to move. It has to re-organise a large part of ScreenInit so things happen in the correct order otherwise some things get setup in-correctly. (not sure EXA with fb not at 0 works yet...)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
enabled by RADEONEnableDisplay().
|
|
for each output.
|
