>
> The linux kernel was upgraded from 3.2.12-1 to 3.2.15-1 in the same install
> session. It is now at 3.2.18-1.
See https://bugs.freedesktop.org/show_bug.cgi?id=43448 , which has a
kernel fix.
--
Earthling Michel Dänzer | http://www.amd.com
L
On Die, 2012-06-12 at 12:28 -0700, Connor Behan wrote:
> On 12/06/12 01:31 AM, Michel Dänzer wrote:
> > I doubt there's any reason why the ring walker method wouldn't work
> > with AGP. BTW, I assume you're always testing your code with direct
> > rendering en
http://www.x.org/wiki/RadeonFeature#KMS_Power_Management_Options
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driv
h, someone would need to step up and take care
of UMS vs. ongoing development.
> we'd fork the current master into a UMS branch and move on.
Sounds good. Might even allow cleaning up the UMS code as well for
someone so inclined.
--
Earthling Michel Dänzer |
xactly? As I pointed out in the
upstream bug report, either of Alex's kernel or libdrm patches alone
should fix the problem. Stefan's patches are incorrect, I just marked
them as obsolete to avoid confusion.
--
Earthling Michel Dänzer | http://www.amd.com
Lib
e able to override this though, either by adding a ModeLine
for "1280x1024" in Section "Monitor" or at runtime using the xrandr
utility.
> [ 286.626] (**) RADEON(0): Display dimensions: (1280, 1024) mm
> [ 286.626] (**) RADEON(0): DPI set to (20, 19)
Probably not directly re
With module dri working (without this module there is no problem)
> Randomly the whole system freezes, as an example playing with extremetuxracer
> package
Does passing radeon.agpmode=1 or radeon.agpmode=-1 on the kernel command
line help?
--
Earthling Michel Dänzer |
ature#KMS_Power_Management_Options ?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http:/
From: Michel Dänzer
It was using the pitch (displayWidth) for the virtual width (virtualX). This
prevented using page flipping in some cases, as displayWidth was already
overaligned for virtualX, so the DRI2 front and back buffers ended up having
a different pitch.
Signed-off-by: Michel Dänzer
ound
> [0.463471] Linux agpgart interface v0.103
Looks like something is preventing the radeon kernel driver from
loading / initializing. Is it built into the kernel or as a module? If
the latter, what happens if you try to run 'sudo modprobe radeon' from
console (ideally before
From: Michel Dänzer
Enable at build time with --enable-glamor and runtime with
Option "AccelMethod" "glamor"
The most notable lack of functionality is XVideo. Use something like VDPAU for
now.
Signed-off-by: Michel Dänzer
---
configure.ac | 14
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/Makefile.am|4 +-
src/radeon.h | 20 ++
src/radeon_bo_helper.c | 177
src/radeon_bo_helper.h | 31 +
src/radeon_exa.c | 160
The main purpose of these changes is to allow using this driver on SI hardware
and playing with the (still quite limited) Gallium radeonsi driver in an X
environment.
Longer term, glamor might be interesting for older Radeons as well. Right now,
its main drawbacks are missing XVideo support (shoul
On Die, 2012-07-10 at 14:06 +0200, Rafał Miłecki wrote:
> 2012/7/10 Michel Dänzer :
> > The main purpose of these changes is to allow using this driver on SI
> > hardware
> > and playing with the (still quite limited) Gallium radeonsi driver in an X
> > environment.
Hi Alex,
(Please trim irrelevant quoted text when following up; doing so would
have prevented your post from getting caught in the moderation queue for
being too big :)
On Die, 2012-07-10 at 09:28 -0400, Alex Deucher wrote:
> On Tue, Jul 10, 2012 at 7:03 AM, Michel Dänzer wrote:
>
On Die, 2012-07-10 at 10:07 -0400, alexdeuc...@gmail.com wrote:
> From: Michel Dänzer
>
> Defaults to shadowfb. 3D acceleration is available with glamor. 2D
> acceleration is disabled until the radeonsi driver can handle glamor's
> shaders.
>
> v2: add chip flags
1024:768. I want
> to get to 1920:1080. Any help is appreciated.
There's no better driver for your card. Please post
the /var/log/Xorg.0.log file and dmesg output corresponding to the
problem.
--
Earthling Michel Dänzer | http://www.amd.com
Libre so
kernel driver
on your card, which probably also explains the resolution problem.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-drive
On Don, 2012-07-12 at 09:25 -0400, Gary Dale wrote:
> On 12/07/12 04:01 AM, Michel Dänzer wrote:
> > On Mit, 2012-07-11 at 13:59 -0400, Gary Dale wrote:
> >> DRM Information from dmesg:
> >> ---
> >> [0.00] No AGP bridge fou
On Don, 2012-07-12 at 10:58 -0400, Gary Dale wrote:
> On 12/07/12 04:01 AM, Michel Dänzer wrote:
> > On Mit, 2012-07-11 at 13:59 -0400, Gary Dale wrote:
> >> DRM Information from dmesg:
> >> ---
> >> [0.00] No AGP bridge fou
uninterruptable sleep state.
One problem is that the firmware-linux-nonfree package doesn't contain
the microcode for Trinity yet. Get the ARUBA_*.bin files from
http://people.freedesktop.org/~agd5f/radeon_ucode/ , put them
in /lib/firmware/radeon/ and re-generate the initrd. Then see what if
28InitDDA2Registers(pScrn, save, &info->pll, info, mode))
> return FALSE;
> }
Changing R128_DEBUG to 1 in r128.h still breaks the build for me with
this patch applied.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthu
cursor.c
> index 62d277d..974a6d5 100644
> --- a/src/r128_cursor.c
> +++ b/src/r128_cursor.c
[...]
> +if ((!info->useEXA && !fbarea) || (info->useEXA && !osArea)) {
osArea is undeclared here if EXA is disabled at build time.
Anyway, I figured this has b
;
> and there it hangs.
Is the X server process still alive at that point? If not, it probably
died due to an unresolved symbol, check its stderr output. Probably
easiest to do this from a remote shell.
--
Earthling Michel Dänzer | http:
Pushed, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listi
On Die, 2012-07-17 at 22:53 -0700, Connor Behan wrote:
> The offscreen area used by EXA needs to be declared even with lazy
> evaluation.
>
> Signed-off-by: Connor Behan
Pushed, thanks!
--
Earthling Michel Dänzer | http://www.amd.com
Libre softwar
deon.disp_priority=2 on the kernel command line
help?
Please provide the output of xrandr --verbose for each case.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
On Son, 2012-07-22 at 13:20 +1000, James Robertson wrote:
> On 21 July 2012 03:45, Michel Dänzer wrote:
> >
> > Can you elaborate on what exactly 'tearing and corruption' means?
>
> I have created a brief video to show the tearing. It occurs when
> basical
onfb with video=radeonfb:off, but
KMS may not work very well with your card.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing
On Die, 2012-08-07 at 04:38 -0700, Dan DeVoto wrote:
> --- On Mon, 8/6/12, Michel Dänzer wrote:
> > >
> > > [ 36.987427] [drm] radeon defaulting to kernel modesetting.
> > > [ 36.987452] [drm] radeon kernel modesetting enabled.
> >
> > You should
On Mit, 2012-08-08 at 01:30 -0700, Dan DeVoto wrote:
> --- On Tue, 8/7/12, Michel Dänzer wrote:
> >
> > > Also, adding video=radeonfb:off did nothing but make my
> > screen darker
> > > and disable my brightness hotkeys, and there was no
> > change in the
On Mit, 2012-08-08 at 01:30 -0700, Dan DeVoto wrote:
> --- On Tue, 8/7/12, Michel Dänzer wrote:
> >
> > > Also, adding video=radeonfb:off did nothing but make my
> > screen darker
> > > and disable my brightness hotkeys, and there was no
> > change in the
#x27;t cause a black screen.
Maybe you can also check what /sys/class/backlight/radeon_bl/brightness
contains when the screen is black and whether writing 128 or other
values between 0 and 255 to it makes a difference.
--
Earthling Michel Dänzer | http://www.amd.com
Lib
On Mit, 2012-08-08 at 15:18 +0200, Michel Dänzer wrote:
> On Mit, 2012-08-08 at 05:00 -0700, Dan DeVoto wrote:
> >
> > Below is dmesg output with video=radeonfb:off in the kernel command line:
> [...]
> > Aug 8 04:05:15 icebook kernel: [ 10.769815] checking generic
gt;
> i have ATI radeon 9200 (aty, rv280)
> agp
> 32Mo vram
If that's an iBook, sounds similar to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683796 .
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X
On Don, 2012-08-09 at 05:11 -0700, Dan DeVoto wrote:
> --- On Wed, 8/8/12, Michel Dänzer wrote:
> > >
> > > I heard that this handover from OFfb to radeon KMS can
> > cause problems in
> > > some cases. Maybe you can try adding video=offb:off to
> > >
I could, of course, report the versions which are
> known to work and which I am currently using.
It's certainly useful to isolate which version of which package
introduced a problem as much as possible.
--
Earthling Michel Dänzer | http://www.amd.com
Lib
On Fre, 2012-08-24 at 13:19 -0500, Theodore Kilgore wrote:
>
> On Fri, 24 Aug 2012, Michel Dänzer wrote:
>
> > On Don, 2012-08-23 at 18:27 -0500, Theodore Kilgore wrote:
> > >
> > > As you can see, it is intended that the "panning" dimensions oug
_tiling(bo, tiling, pitch) == 0)
> *new_tiling = tiling;
I think you also need to prevent the acceleration code from using
RADEON_GEM_DOMAIN_VRAM when these are used for the destination, or they
will be migrated into VRAM anyway?
--
Earthling Michel Dänzer |
essed up.
Please elaborate what 'all the colors are messed up' means exactly.
E.g.: Does this affect all applications, or only some of them, e.g.
those using OpenGL? Is the problem captured in a screenshot? If not, can
you provide a photograph showing the problem? ...
p leaking from X into console is
probably a kernel issue.
The other problem might be a core X server issue.
In general, the drivers will just set the gamma ramp when/as the
kernel / X server requests, not by themselves.
--
Earthling Michel Dänzer | http://www.amd.com
sa-dri, though it might also be a kernel issue,
see e.g. https://bugs.freedesktop.org/show_bug.cgi?id=35457 .
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
_
and also /var/log/dmesg which all recorded absolutely
> nothing relevant to the event. And the Xorg.log seems not to be saying
> anything, either, other than X has been exited.
Please provide the Xorg.0.log file corresponding to the problem anyway.
--
Earthling Michel Dänzer |
he required microcode is.
> But according to
> http://packages.debian.org/wheezy/all/firmware-linux-nonfree/filelist
> this doesn't exist for wheezy?
As the suffix -nonfree implies, it's in non-free.
--
Earthling Michel Dänzer | http
solving the issues with KMS. Please
provide logs for the issues described above.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati m
o reboot the machine.
>
> Any suggestions.
Can you try a newer kernel, one based on upstream version 3.5.1 or at
least 3.2.25 or newer? Those versions have a fix that might help.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
cking store setup */
> -xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, RADEON_LOGLEVEL_DEBUG,
> - "Initializing backing store\n");
> -miInitializeBackingStore(pScreen);
> xf86SetBackingStore(pScreen);
Isn't that needed for xserver 1.13 and older?
ling acceleration" of course.
>
> Would you guys accept a kernel patch to move this to just a normal
> kernel warning message?
Hard to say without seeing the patch. :)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
ipFamily >= CHIP_FAMILY_R600) {
Please update man/radeon.man accordingly.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
your dmesg output.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/lis
On Fre, 2012-11-09 at 14:52 +0100, Meike Reichle wrote:
> Michel Dänzer @ 09/11/12 10:03:
> > On Fre, 2012-11-09 at 09:12 +0100, Meike Reichle wrote:
> >>
> >> I am using a standard Debian kernel (linux-image-3.2.0-4-686-pae) but
> >> apparently no KMS, I suppo
if the window origin doesn't lie at the pixmap
origin...)
OTOH if the pixmap is smaller than the window, I don't think this change
will do the right thing for RepeatNormal or RepeatReflect.
Not sure rendercheck tests such corner cases at all yet.
--
On Die, 2012-11-13 at 13:59 -0500, Jerome Glisse wrote:
> On Tue, Nov 13, 2012 at 4:30 AM, Michel Dänzer wrote:
> > On Mon, 2012-11-12 at 16:11 -0500, j.gli...@gmail.com wrote:
> >>
> >> diff --git a/src/evergreen_exa.c b/src/evergreen_exa.c
> >> index 88
te = FALSE;
> + if (exaGetPixmapDriverPrivate(pixmap) == NULL) {
> + /* this happen if pixmap is non accelerable */
> + goto error;
> + }
> }
>
> if (is_glamor_pixmap)
Does radeon_dri2_create_buffers() need similar treatment? Otherwise
Re
is is
only scratching the surface of cases we're not handling correctly for
window pictures. If you don't want to more accurately test for the cases
we are handling correctly, I think it might be better to always fall
back for window pictures
or -ati with acceleration disabled).
We are getting close to making the radeonsi shader compiler handle all
the glamor shaders (only support for loops seems missing), so hopefully
we can enable full 2D acceleration on SI soon.
--
Earthling Michel Dänzer |
On Don, 2012-11-15 at 10:47 -0500, Jerome Glisse wrote:
> On Thu, Nov 15, 2012 at 5:08 AM, Michel Dänzer wrote:
> > On Mit, 2012-11-14 at 16:26 -0500, j.gli...@gmail.com wrote:
> >> From: Jerome Glisse
> >>
> >> This is some kind off degenerate case that
On Mon, 2012-11-19 at 13:34 +0530, Balasubramanian S wrote:
> Hello Alex and Mike,
Who's Mike? ;)
> do we have the functionality for delete also?
I'm not sure what you mean by that, can you elaborate?
--
Earthling Michel Dänzer | http://w
t sure we can support that
yet, possibly via the VGA switcheroo functionality.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mai
ld be clear enough for VLC to know it can't use XVideo.
It should be useful to determine which output VLC does end up actually
using, and where it hangs...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X
On Fre, 2012-11-23 at 17:24 +0100, Meike Reichle wrote:
> Michel Dänzer @ 09/11/12 15:32:
> >
> > If that still doesn't explain it, can you try passing radeon.modeset=1
> > on the kernel command line and see if that enables it?
>
> That did the trick. With t
+ }
Looks good to me, assuming there's no better way to avoid getting into
this situation in the first place.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
s there's no evidence of a radeon (or other)
driver bug yet. At the least, please determine which video output VLC
actually ends up using, and where it's hanging, before reassigning back
to any X package.
--
Earthling Michel Dänzer | http://www.amd.com
Libre
running, check if the window's swap interval has
elapsed since the last swap (using the refresh rate of the relevant
CRTC's current / last set mode). If it hasn't, suspend the client until
it has before doing the swap with a blit.
--
Earthling Michel Dänzer |
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
From: Michel Dänzer
../../src/radeon_probe.c: In function 'radeon_platform_probe':
../../src/radeon_probe.c:270:11: error: unused variable 'path'
[-Werror=unused-variable]
Signed-off-by: Michel Dänzer
---
src/radeon_probe.c |1 -
1 file changed, 1 deletion(
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c |2 --
src/evergreen_textured_videofuncs.c | 12
src/r600_textured_videofuncs.c | 12
src/radeon_textured_videofuncs.c| 12
4 files changed, 38
From: Michel Dänzer
Pointed out by clang:
../../src/radeon_kms.c:1562:6: warning: variable 'total_size_bytes' is
uninitialized when used here [-Wuninitialized]
total_size_bytes += (64 * 4 * 64);
^~~~
../../src/radeon_kms.c:1557:25: note: init
From: Michel Dänzer
Not actually used for anything. Refactoring gone wrong?
Also remove a comment that doesn't seem to make sense anymore.
Stumbled over this due to a warning by clang:
../../src/radeon_kms.c:1562:6: warning: variable 'total_size_bytes' is
uninitialized
ce are
> never freed (pixmaps and Misc counters grows indefinitely and also
> their memory occupation).
Do the leaked resources persist when the application terminates?
This is most likely an oxygen-gtk / GTK+ issue.
--
Earthling Michel Dänzer | http://
On Mit, 2012-12-12 at 13:14 +0100, bluebubble wrote:
> Il 12/12/12 12:35, Michel Dänzer ha scritto:
> > On Mit, 2012-12-12 at 12:22 +0100, bluebubble wrote:
> >>
> >> as the title state i'm noticing huge memory leaks with oxygen-gtk
> >> theme under KDE.
On Mit, 2012-12-12 at 15:48 +0100, bluebubble wrote:
> Il 12/12/12 15:29, Michel Dänzer ha scritto:
> > On Mit, 2012-12-12 at 13:14 +0100, bluebubble wrote:
> >> Il 12/12/12 12:35, Michel Dänzer ha scritto:
> >>> On Mit, 2012-12-12 at 12:22 +0100, bluebubble wro
On Mit, 2012-12-12 at 18:56 +0100, bluebubble wrote:
> Il 12/12/12 17:42, Michel Dänzer ha scritto:
> > On Mit, 2012-12-12 at 15:48 +0100, bluebubble wrote:
> >> Il 12/12/12 15:29, Michel Dänzer ha scritto:
> >>> On Mit, 2012-12-12 at 13:14 +0100, bluebubble w
ing the swap, but a significant part of that (or even more
time) might have passed already since the last swap of the drawable. You
could keep track of the previous swap time (from the event tv_(u)sec
values or GetTimeInMillis()) in a drawable private and only wait for the
amount of time actually nec
On Fre, 2012-12-14 at 10:55 +0100, Michel Dänzer wrote:
> On Don, 2012-12-13 at 14:46 -0500, Ilija Hadzic wrote:
> > @@ -1337,6 +1345,20 @@ static int radeon_dri2_schedule_swap(ClientPtr
> > client, DrawablePtr draw,
> >
On Fre, 2012-12-14 at 12:03 -0500, Ilija Hadzic wrote:
> On Fri, Dec 14, 2012 at 4:55 AM, Michel Dänzer wrote:
> >> +/*
> >> + * CRTC is in DPMS off state, fallback to blit, but pace the
> >> + * application at the rate that roughly approximates the
>
ted. Just calculate the delta as a
subtraction of two uint64_t values (so wraparounds are handled
naturally) and cast it to int64_t for testing < 0.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI de
n doing something in
particular, or randomly?
Does upgrading to libdrm-radeon1 2.4.40-1 from experimental help for
this?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
__
Not very nice...
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
--- Begin Message ---
This is the mail system at host darkcity.gna.ch.
I'm sorry to have to inform you that your message
this your
> way.
It's not about my (or anyone's) way, but I think there's two basic
approaches:
1. Mimic the behaviour with a running CRTC as closely as possible
2. Don't bother, just always wait for a fixed amount of time, say
some fraction of a second
On Die, 2012-12-18 at 21:25 -0500, Ilija Hadzic wrote:
> On Tue, Dec 18, 2012 at 1:07 PM, Michel Dänzer wrote:
> >
> > 1. Mimic the behaviour with a running CRTC as closely as possible
> > 2. Don't bother, just always wait for a fixed amount of time, say
>
On Mit, 2012-12-19 at 10:18 -0500, Ilija Hadzic wrote:
> On Wed, Dec 19, 2012 at 5:24 AM, Michel Dänzer wrote:
> >
> > In the original thread about this problem, you asked what the right
> > thing to do would be. I gave my opinion on that, basically option 1
> > abov
27.html
>
> In this series all attempts to be "smart" and emulate the real
> CRTC behavior have been thrown away. Instead, when CRTC is disabled
> we just defer the swaps by a hard-coded constant, with the sole
> objective to prevent unecessary power dissipation.
Th
27.html
Series pushed, thanks and Happy New Year.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driver-ati@l
.]
> [56.923] (II) RADEON(0): KMS Color Tiling: enabled
Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=34486
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
__
g: enabled
Does
Option "ColorTiling" "off"
prevent the problem? (Verify in the log file that the option takes
effect)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
52B, Need:
> 7119360B, Info:
> r300: texture_desc_init: Macro: NO, Micro: YES, Pitch: 1728, Dim:
> 1678x1029x1, LastLevel: 0, Size: 7119360, Format: s8_uint_z24_unorm
[...]
> Maybe related to https://bugs.freedesktop.org/show_bug.cgi?id=42085
Looks like it. I attached a patch that
On Don, 2013-01-10 at 10:14 +0100, Tilo Schwarz wrote:
> On Thu, 10 Jan 2013 09:16:37 +0100, Michel Dänzer
> wrote:
>
> > On Mit, 2013-01-09 at 20:01 +0100, Tilo Schwarz wrote:
> >>
> >> Indeed, using
> >>
> >> % grep ColorTiling /etc/X11/x
From: Michel Dänzer
The main purpose is to drop DRI2 compatibility code paths which are getting
awkward to deal with and at this point are probably only tested lightly if at
all. xserver 1.7 was released more than 3 years ago, and 1.6.2 was already
required before.
Mostly mechanical, there&#
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/radeon_dri2.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index f0c5c01..36a44e4 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -164,6
From: Michel Dänzer
Fixes piglit sanity.tests (with 3D drivers which allocate depth buffers from
the X server).
Signed-off-by: Michel Dänzer
---
Tested on RV350.
src/drmmode_display.c | 4 +++-
src/radeon.h | 1 +
src/radeon_dri2.c | 10 --
3 files changed, 12
On Mon, 2013-01-14 at 23:29 +0100, bluebubble wrote:
> Il 13/12/12 10:46, Michel Dänzer ha scritto:
> > If yes, you'll need to investigate the leak with valgrind or some other
> > tool for this. Note that such tools may not help on X server shutdown,
> > as the X ser
On Don, 2013-01-17 at 09:13 +0100, bluebubble wrote:
> Il 15/01/13 09:16, Michel Dänzer ha scritto:
> > As you can see, the X server hardly leaked any memory on exit. You
> > really need to trigger valgrind to print information about where memory
> > was allocated from while
ut a tool which
> would enlighten the situation?
Ben, any pointers for this?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver
g the generic
driver from xserver-xorg-video-fbdev in that case.
I suspect your kernel is missing upstream fixes for your GPU.
Meanwhile, Option "NoAccel" should allow you to use at least the basic
display related features of xserver-xorg-video-radeon.
--
Earthling Michel Dänzer
ndline might
help.
> [ 596.217] (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR
> disabled
> message.
> [ 596.217] (--) RandR disabled
As you can see, RandR 1.2 is enabled, the second message is an artifact
of how RandR 1.2 support is initialized in the X server.
--
it's still processing client requests?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
On Mon, 2013-02-04 at 13:51 +, Tony Houghton wrote:
> On Mon, 04 Feb 2013 11:31:11 +0100
> Michel Dänzer wrote:
>
> > On Sam, 2013-02-02 at 19:15 +, Tony Houghton wrote:
> > >
> > > I share the keyboard, mouse and one of two monitors between this
fault here, and I fail to see what else it could do. If
> shaders are so slow, the driver should not offer them in the first place.
Why do you think the problem is that 'shaders are slow'?
Without knowing where VLC is hanging, and/or at least seeing the output
of glxinfo, don&#x
On Mit, 2013-02-06 at 12:16 +0100, Rémi Denis-Courmont wrote:
> On Wed, 06 Feb 2013 11:18:19 +0100, Michel Dänzer
> wrote:
> >> The fact that it works just fine when plain X11 output is forced in the
>
> >> preferences proves that X11 would work fine, but is not
601 - 700 of 1284 matches
Mail list logo
