Age | Commit message (Collapse) | Author |
|
This updates the compat stuff for the latest block handler code,
and the enable/disable interface.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This was missing the compat include.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
I missed these in my initial search/replace for some reason.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Just pass the ScrnInfoPtr around instead.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Just pass a pointer to the screen, removes usage of xf86Screens lookup
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
The compat header takes care of the old server vs new server.
this commit was autogenerated from util/modular/x-driver-screen-scrn-conv.sh
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
This isn't needed, and makes api changes later easier.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
Those formats were invented for exactly that purpose so use them.
This saves some code and also some hw resources (only need one
sampler instead of two for packed yuv).
Only tested on EG.
|
|
make sure the division is done with floats, otherwise the coordinate
can be wrong up to 1 texel.
Particularly visible with clipping and small source scaled up (since one
texel can be a shift of several pixels) but could be seen even unscaled.
Should provide more accurate coords without clipping too depending on the
scale factor probably.
This is a straight port of 688c8a54a00b01e73a11970ad2abe858f8c7c5c4
when I apparently forgot the eg code...
|
|
Should make bugs like https://bugs.freedesktop.org/show_bug.cgi?id=48138
easier to diagnose.
[ Michel Dänzer: Appended newline to error message. ]
Signed-off-by: Anisse Astier <anisse@astier.eu>
Singed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
UMS doesn't do this automagically. It's a big hammer that will probably suck
for performance, but I don't have any better ideas right now.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Only compile tested, but should fix
https://bugs.freedesktop.org/show_bug.cgi?id=49182 .
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Allocate 1x1 scratch pixmaps to hold the solid picture colours.
This works around https://bugs.freedesktop.org/show_bug.cgi?id=47266 and might
improve performance in other cases as well.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
It was the same code as for RADEON_HOST_DATA_SWAP_32BIT. This caused bus errors
on FreeBSD/PPC, but I'm not sure how it could not cause problems anywhere...
Reported-by: Andreas Tobler <andreast@fgznet.ch>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
So that bugs like https://bugs.freedesktop.org/show_bug.cgi?id=48138 can be
diagnosed more easily.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Due to some old kernel issue, height is 8 aligned insided the ddx
For buffer with height btw 57 & 63 this lead ddx to believe it can
allocate a 2D tiled surface while mesa will not align height and
will assume 1D tiled leading to disagreement and rendering issue.
This patch force buffer with height < 64 to be 1D tiled.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
- KMS only
- Includes full EXA/Xv support
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
If Mesa set it to 1, the DDX would not render anything = the monitor would
basically freeze.
agd5f: update emit count as well.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Deferring this could result in trying to unreference buffers from a previous
server generation, i.e. accessing freed memory.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Christian König <Christian.koenig@amd.com>
|
|
Fixes hang when trying to use DRI2 swap scheduling after a server reset.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Christian König <Christian.koenig@amd.com>
|
|
The sam440ep PPC board requires a ConnectorTable xorg.conf option, but putting
in that option causes the radeon driver to crash. I finally traced it to a
copy-and-paste bug in radeon_output.c as a result of a major rework in commit
82f12e5a40c1fbcb91910a0f8b725c34fff02aae.
The actual crash occurred in RADEONPrintPortMap().
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
make sure the division is done with floats, otherwise the coordinate
can be wrong up to 1 texel.
Particularly visible with clipping and small source scaled up (since one
texel can be a shift of several pixels) but could be seen even unscaled.
Should provide more accurate coords without clipping too depending on the
scale factor probably.
Changed for r100-r600, though only tested on r300.
|
|
In path where we need to use scratch bo as temporary area,
consider it as linear buffer. Not linear aligned. Fix some
case such as in bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=45827
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45937
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Only init surface on r6xx+. Return NULL rather than
FALSE.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=45829
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
It's standard behavior.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Avoids an accounting bug in libdrm_radeon 2.4.31 or older.
See https://bugs.freedesktop.org/show_bug.cgi?id=43893
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
And some UMS specific warnings.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Pointed out by gcc -Wunused-variable.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Fixes crash reported by Ole Salscheider on IRC.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
|
|
Should also fix xv for some case.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
Use libdrm common surface code so mesa,ddx have same idea
about tiling surface and what their pitch should be and
the alignment constraint.
v2 fix remaining issue add new option to conditionaly enable
v3 fix fbcon copy and r600 exa copy path
v4 fix non tiled path 2D tiling on GPU >= R600, set it to false
as default
v5 adapt to pixel/element size split of libdrm/radeon
v6 update to properly handle falling back to 1d tiled
v6 final fix to tile split value on evergreen and newer
v7 fix default array mode on r6xx, fix height alignment issue
on evergreen
v8 fix tile split value
v9 add stencil tile split support, simplify dri2 for stencil
with evergreen
v10 Try to fix xv path regarding tiling. Adapt to libdrm API
change. Try to fix case where there is no surface which
means non tiled bo.
v11 check for proper libdrm
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
|
|
The range passed in is in pixmap coordinates, so the CRTC offset needs to be
added to the clamping limits and subtracted from the clamped range for
pre-AVIVO display engines.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The clamping could turn a previously non-empty range into an empty one.
Also, start == stop means the range is empty.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Need to use GXCopy for the src to temp copy, then
the original rop for the temp to dest copy.
Noticed by: Frank Huang
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|
|
RADEONRestore() calls crtc->funcs->dpms() after most of the mode setting
subsystems have been restored. This function enables the CRTCs but does
more: it calls DRM pre- and post-modeset ioctls and sets up the palettes
(LUTs).
None of these two things are needed. Accessing the palette registers after
restoring the PLLs can even lead to lockups.
Thus the CRTC DPMS function is split into two parts: one that just enables
/disables the CRTC and one which wraps this function and does the rest.
Now the inner function can be called directly from RADEONRestore() as
there is no need to go thru the RandR hooks in this function while the
RandR hook uses the wrappering function so the full functionality is
preserved from an RandR point of view.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
|
|
The reintroduction of palette save/restore in 5efdf514 causes some
pre-AVIVO chips to lock up. An investigation revealed that accessing
palette registers when the associated PLL is not running is causing
this. With UMS the PLL setup that is saved has been done by the BIOS
typically.
A similar issue was observed when VGA palette save/restore had
been reinitroduced with 80eee856:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480312
and has been worked around for Linux without further investigation
by 87e66ce7.
To fix the issue we now
a. introduce 'on-demand' palette saving (ie the palette is
saved before it is first altered). This guarantees that
the palette register are only associated when the associated
CRTC is active and thus the PLLs are powered up and running.
b. move palette restore before PLL restore.
c. eliminate generic VGA palette save/restore which seems to be
unneeded when the palette is restored natively.
It is believed that this caused the behavior described in
https://bugs.freedesktop.org/show_bug.cgi?id=18407#c27
Signed-off-by: Egbert Eich <eich@freedesktop.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
|
|
Signed-off-by: Matthieu Herrb <matthieu.herrb@laas.fr>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
|