| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Move code where it's used, remove unused variables, etc.
|
|
probably requires testing on other r300 based cards, with the syncs in
we hang when moving the cursor into the second CRTC.
|
|
Conflicts:
src/radeon_cursor.c
src/radeon_display.c
src/radeon_driver.c
|
|
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.
|
|
|
|
- quick fix for the cursor handling to update to the latest
server bits
- make sure connector type is CONNECTOR_PROPRIETARY for LVDS.
|
|
and it breaks my cursor
|
|
|
|
Also fixup secondary dac detect to return unknown for now
|
|
|
|
|
|
|
|
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...)
|
|
|
|
As a result, quite a bit of code can be removed that attempted to deal with the
EXA offscreen memory disappearing, with varying success. Because the HW cursor
memory is now always immediately after the front buffer and before the back
buffer, this also fixes bug #6808.
As the HW cursor memory is now reserved statically with EXA and XAA, change
RADEONUseHWCursor() to check info->cursor instead of info->cursor_offset, for
which 0 might become valid with HW cursor enabled in the future.
Change info->cursor_offset from unsigned long to CARD32 as the corresponding
register is 32 bits wide, and to avoid issues with printf.
|
|
|
|
detects available & accessible video memory and initializes the card
internal memory map. Along the way, I re-ordered some of the stuffs in
pre-init in order to remove some dodgy codepath, fixed various init,
exit and vt switch issues, and overall made the driver more robust. The
full memory map fix requires an updated DRM. The X driver no longer
tries to position the AGP aperture, this becomes entirely DRM
responsibility.
|
|
attachment #3689 (http://bugs.freedesktop.org/attachment.cgi?id=3689)
Fix HW cursor getting silently disabled with EXA.
|
|
controlled at compile time, plus the runtime option of Option
"AccelMethod" "EXA" or "XAA". The XAA support appears to remain as
before, while the EXA pieces need just a little more polishing. Notable
features:
- Render acceleration working on Radeon 100 and 200-series with DRI on.
- DRI works with EXA Notable issues:
- DGA disabled in the EXA case.
- Backbuffer moves disabled in the EXA case.
- No textured XVideo.
- MMIO render acceleration is close but still has some issues.
- Memory pressure while using Composite is really troublesome with DRI on.
This patch is based on an initial patch by Zack Rusin, with significant
work by Benjamin Herrenschmidt and myself.
|
|
|
|
attachment #2230 (http://bugs.freedesktop.org/attachment.cgi?id=2230)
Wait for idle before uploading HW cursor data to the framebuffer to
avoid lockups when moving the mouse on some machines.
|
|
Hui Yu)
|
|
aperture on big endian machines, remove superfluous local variables and
register reads.
Adapt framebuffer aperture byte swapping to texture format before copying
data to offscreen area and restore it afterwards on big endian
machines, fixes Render acceleration there.
reviewed by: Hui Yu <hyu@ati.com>, Kevin E. Martin <kem@freedesktop.org>
|
|
with the following notes:
- Savage and Mach64 (= ati/ati*.[ch] changes) DRI not merged due to
insecurity.
- VIA driver converted to new drmContext and drmHandle names.
- Radeon driver merge conflicted in many places, and MergedFB at least
could probably use some checking at this point.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
