| Age | Commit message (Collapse) | Author |
|---|
|
Also fix some RADEON_ALIGN(x, 63), which would return incorrect results
for odd x. Though this shouldn't happen, it's still not right. You
wouldn't ever write (x + 62) & ~62 which is clearly wrong (and what it
expands to).
CC: Jerome Glisse <jglisse@redhat.com>
CC: Alex Deucher <alexdeucher@gmail.com>
CC: Dave Airlie <airlied@redhat.com>
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
Taken from James patch on bug 24523
agd5f: adapt to the current code
|
|
Now that the screen section mapping is fixed,
Make the option per-instance and allow multiple
outputs to be specified; e.g., DVI-0 and HDMI-0
associated with instance 0 and LVDS and VGA-0
associated with instance 1.
|
|
|
|
Allows users that want to use zaphod mode to select
which xrandr outputs are assigned to which head. E.g.,
Option "ZaphodHeads" "LVDS,VGA-0"
will assign LVDS to the first zaphod driver instance
and VGA-0 to the second instance.
|
|
|
|
When acceleration is disabled we need to reallocate
a new shadow framebuffer and we should also avoid
calling any EXA function as EXA is disabled in such
case.
|
|
|
|
When we resize the front buffer we need to reduce the flush limits
appropriately.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
We have to translate from the kernel encoder cloning to the randr
connector cloning, we do this by constructing an encoder mask per output
and an encoder cloning mask per output then comparing them.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This reverts commit 60d9685abddccec17c1a9a5ec48cbe9c92543e0f.
which breaks colormap on 1.6 X server
Conflicts:
src/drmmode_display.c
|
|
use our own wrapper to allocate a pixmap for wrapping a bo in.
|
|
|
|
Passing null in here stops the mixed pixmap code doing it wrong,
but I'm not 100% sure how it is meant to work, we have the
same issue with the real front bo by the looks of it.
|
|
for correct colormap operation you probably want 1.7
|
|
scratch pixmaps seem to interact badly with mixed pixmaps, it appears
some state may be getting left around in the privates somewhere, since
scratch pixmap headers don't get destroyed.
|
|
We need to program the gamma at modeset. no need to use
old cmap interface at all.
|
|
Requires at least xserver 1.7 to work properly.
Also make sure the front buffer is and stays tiled if colour tiling is enabled.
|
|
This will fallback to shadowfb is GPU accel failed somewhere during
KMS kernel init.
|
|
this adds support to the userspace DDX to get properties from the kernel
and expose them over randr. Its most liberated from the Intel driver.
|
|
|
|
Fixes build against older xserver.
|
|
Otherwise some things like changing the colour map won't work properly.
|
|
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>
|
|
|
|
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
|
