Most of KMS building was disabled if LIBDRM_RADEON was not detected. But at
least configure was reporting KMS enabled even tough it was realy disabled.
DPMS header was split into dpms.h (client) and dpmsconst.h (server). Drivers
need to include dpmsconst.h if xextproto 7.1 is available.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Build break: Makefile.am: command not found: git-log
Adding the macro in configure.ac and use it in Makefile.am
Refer to: https://bugs.freedesktop.org/show_bug.cgi?id=22611
Tested: running autogen.sh, make and 'make dist'
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds DRI2 + KMS + driver pixmaps support to the driver.
I've decided to just do a completely separate KMS driver file
instead of hacking the crap out of radeon_driver.c. So now
I do the KMS check in radeon_probe.c time and set the DDX
pointed up to a completely different set at this stage.
This avoids a lot of if (kms) type crap in the code at
the expense of making sure we make changes to both files
if necessary.
This code is still disabled in configure.ac as I broke EXA composite
rendering somehow in KMS mode
This patch contains most of the changes to the EXA and texture video
accel code.
It adds a few bits of pixmap support but doesn't actually do anything
useful KMS yet.
Testing this should not have any regressions over what we have already,
biggest worries are r6xx, I've fixed a textured video one, but no idea
what other might lurk
It won't build against libdrm radeon yet either
The PrepareAccess hook can now get six different indices.
Also remove superfluous instances of #include "exa.h".
Note that you may need to run autoheader manually to get config.h.in updated.
egrep LOADER\|SymLists\|Symbols src/*.[hc]
not needed after server commit bca9364f3f4a2376edbcf57a34f704ce28be21ba, i.e.
xserver 1.2
compile-tested only
The old code would attempt to limit the maximum pixel size of the screen
by limiting the maximum PLL frequency. This ends up confusing the PLL
computation code since sometimes your maximum freq can be lower than your
minimum freq. More to the point it's just wrong, maximum PLL frequency
isn't the same thing as maximum pixel clock, and even that isn't the same
thing as maximum scanout pixels per second.
The correct thing to do is filter by the mode's effective memory bandwidth.
