| Age | Commit message (Collapse) | Author |
|---|
|
ATI provides the following algorithm to calculate the RMX scaling ratios
in its programming specs:
when RMX_AUTO_RATIO_HORZ_INC set to 1,Horizontal auto ratio result trucated,
and then incremented by 1.
Horz_Ratio = ( ((Active display width in characters (including overscan) + 1)
/ (Panel width in characters)) x 4096 + 1 )
else
Horz_Ratio = ( ((Active display width in characters (including overscan))
/ (Panel width in characters)) x 4096 + 1 )
when RMX_AUTO_RATIO_VERT_INC set to 1, Vertical auto ratio result trucated,
and then incremented by 1.
Vert_Ration = ( ((Active display width in characters (including overscan) + 1)
/ (Panel width in characters)) x 4096 + 1)
else
Vert_Ration = ( ((Active display width in characters (including overscan))
/ (Panel width in characters)) x 4096 + 1)
This patch implements this behavor. Additionally it avoids the use of floats.
|
|
Spotted by otaylor and MrCooper
|
|
xrandr uses PictOpSrc for rotation which we were falling back on since
render semanties require alpha=0 for REPEAT_NONE when there is no alpha
channel and there is a transform. If the dst has no alpha channel we
should be ok I think.
Otayler and I discussed this on IRC. the more general fix would be
to clip the dst to the src and mask for bounded ops like in/add/over
in the pixel exact transform case.
|
|
|
|
|
|
RS400 (intel based IGP) and RS480 (AMD based IGP) have different
MC setups and need to be handled differently
|
|
The compiler pointed this out...
|
|
As has been done with xf86-video-intel, replace all CARD* datatypes with
uint*_t datatypes available from stdint.h.
|
|
see debian bug 480312
|
|
|
|
So it appears we have in the wild two chipsets with the same PCI ID (0x1002:0x5974)
that are mobile and non-mobile.
the RH bug references is a desktop system.
The Dell Vostro 1100 also has this chipset with LVDS bits.
|
|
airlied - This code was originally written by Alex, and I've modified it to
only run on single-CRTC cards for now until we can test it some more.
|
|
|
|
The MMIO paths eventually lead to a hang on r5xx/IGP. I haven't
been able to find out why yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We don't need to add fbOffset here as the mmap we have of the framebuffer
starts half way.
|
|
Atombios redefines the standard types but the definitions conflict
with the ones from glibc (causes build failures on GNU/Hurd
and GNU/kFreeBSD).
|
|
|
|
this should fix occasional corruption seen when updating
the cursor.
|
|
- free rotate pixmaps on VT switch
- save crtc/output status so we only turn on
crtcs/outputs if they are off
- show/hide cursors when changing modes
|
|
see bug 15538
|
|
|
|
Also add more bit defs to wait_until register
|
|
|
|
When we can't turn on hardware repeats, because the texture
is non-power-of-two, or has padding at the ends of lines,
try to draw the image in multiple tiles rather than falling
back to software. (We can only do this when there is no
transform.)
|
|
Actually enable repeats for R100 and R200. This corresponds
to a R300 change made in the patch in:
http://bugs.freedesktop.org/show_bug.cgi?id=15333
|
|
- pre-load r3xx tex instructions
- setup RS instructions in init3d()
|
|
Adapted from Owen's patch on bug 15546
This fixes the slowness with aatext on r300
and may speed up other chips marginally.
|
|
|
|
this fixes tcl/pvs on RV515 among other things
|
|
wait in CompositeDone() instead
|
|
|
|
- document the R300 exa/textured video code
- minor cleanups of textured video code to clarify meaning
|
|
- Move more code to init3d()
- MMIO textured video seems more reliable now on newer chips
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
function"
This reverts commit 305a3310963a5dd07b3495015b06aa8c7c4e6b02.
Conflicts:
src/radeon_commonfuncs.c
src/radeon_exa_render.c
src/radeon_textured_videofuncs.c
|
|
|
