Re: Am I using the ati or vesa driver?
On Thu, 31 Jul 2014 23:14:34 +0900 Michel Dänzer mic...@daenzer.net wrote: On 31.07.2014 19:47, YuGiOhJCJ Mailing-List wrote: I give you my full Xorg.0.log here: http://pastebin.com/fsPBgt5P If you find an interesting line telling me what driver I am using please highlight it for me. The radeon driver fails to initialize because of this: [ 1684.773] (II) [KMS] drm report modesetting isn't supported. Check the dmesg output for why the radeon kernel driver isn't active. Indeed, this problem is because my radeon module is not loaded: $ lsmod | grep radeon So, I load it: $ sudo modprobe radeon Then after it I restart X, then I got: $ sudo dmesg | grep drm [ 5516.131529] [drm] Initialized drm 1.1.0 20060810 [ 5516.191147] [drm] radeon kernel modesetting enabled. So, it seems to be good now. No, there should be a lot more output. I suspect the kernel is too old to support your Kabini GPU. Indeed, my kernel was too old. I have upgraded from linux-3.10.17 to linux-3.15.8 and now it works: $ sudo dmesg | grep drm [7.256525] [drm] Initialized drm 1.1.0 20060810 [7.356838] [drm] radeon kernel modesetting enabled. [7.359272] [drm] initializing kernel modesetting (KABINI 0x1002:0x9839 0x1043:0x141D). [7.359484] [drm] register mmio base: 0xFEB0 [7.359607] [drm] register mmio size: 262144 [7.359781] [drm] doorbell mmio base: 0xD000 [7.359903] [drm] doorbell mmio size: 8388608 [7.360705] [drm] Detected VRAM RAM=512M, BAR=256M [7.360882] [drm] RAM width 128bits DDR [7.361827] [drm] radeon: 512M of VRAM memory ready [7.361951] [drm] radeon: 1024M of GTT memory ready. [7.362102] [drm] Loading KABINI Microcode [7.444224] [drm] Internal thermal controller without fan control [7.445271] [drm] radeon: dpm initialized [ 39.111953] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 39.134989] [drm] PCIE GART of 1024M enabled (table at 0x00277000). [ 39.139336] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 39.139466] [drm] Driver supports precise vblank timestamp query. [ 39.139855] [drm] radeon: irq initialized. [ 39.143992] [drm] ring test on 0 succeeded in 3 usecs [ 39.144211] [drm] ring test on 1 succeeded in 3 usecs [ 39.144368] [drm] ring test on 2 succeeded in 3 usecs [ 39.144825] [drm] ring test on 3 succeeded in 3 usecs [ 39.144964] [drm] ring test on 4 succeeded in 2 usecs [ 39.201193] [drm] ring test on 5 succeeded in 2 usecs [ 39.221352] [drm] UVD initialized successfully. [ 39.221990] [drm] ib test on ring 0 succeeded in 0 usecs [ 39.222412] [drm] ib test on ring 1 succeeded in 0 usecs [ 39.222815] [drm] ib test on ring 2 succeeded in 0 usecs [ 39.223238] [drm] ib test on ring 3 succeeded in 0 usecs [ 39.223653] [drm] ib test on ring 4 succeeded in 0 usecs [ 39.244927] [drm] ib test on ring 5 succeeded [ 39.282221] [drm] radeon atom DIG backlight initialized [ 39.282369] [drm] Radeon Display Connectors [ 39.282497] [drm] Connector 0: [ 39.282623] [drm] LVDS-1 [ 39.282746] [drm] HPD1 [ 39.282873] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [ 39.283071] [drm] Encoders: [ 39.283217] [drm] LCD1: INTERNAL_UNIPHY [ 39.283345] [drm] Connector 1: [ 39.283470] [drm] HDMI-A-1 [ 39.283593] [drm] HPD2 [ 39.283717] [drm] DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c [ 39.283915] [drm] Encoders: [ 39.284040] [drm] DFP1: INTERNAL_UNIPHY [ 39.284166] [drm] Connector 2: [ 39.284301] [drm] VGA-1 [ 39.284427] [drm] DDC: 0x65c0 0x65c0 0x65c4 0x65c4 0x65c8 0x65c8 0x65cc 0x65cc [ 39.284626] [drm] Encoders: [ 39.284751] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 39.386891] [drm] fb mappable at 0xC047B000 [ 39.387031] [drm] vram apper at 0xC000 [ 39.387156] [drm] size 4325376 [ 39.387287] [drm] fb depth is 24 [ 39.387411] [drm]pitch is 5632 [ 39.387731] fbcon: radeondrmfb (fb0) is primary device [ 39.440530] radeon :00:01.0: fb0: radeondrmfb frame buffer device [ 39.453620] [drm] Initialized radeon 2.38.0 20080528 for :00:01.0 on minor 0 Now, all my previous problems are solved: - 1 screen only used (the external VGA screen): solved! (the two screens are working together) - the font is too big: solved! (the font size is normal) - the xrandr command tells me Failed to get size of gamma for output default: solved! (this message is not displayed anymore) But I see a last problem: I have no 3d acceleration! As you can see here: $ cat /var/log/Xorg.0.log | grep Direct [ 7567.271] (WW) RADEON(0): Direct rendering disabled The full xorg log is available here: http://pastebin.com/hSKjXsvL Do you know how to have 3d acceleration please? Thank you. Best regards. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info:
Re: Am I using the ati or vesa driver?
On 04.08.2014 21:03, YuGiOhJCJ Mailing-List wrote: But I see a last problem: I have no 3d acceleration! As you can see here: $ cat /var/log/Xorg.0.log | grep Direct [ 7567.271] (WW) RADEON(0): Direct rendering disabled The full xorg log is available here: http://pastebin.com/hSKjXsvL Do you know how to have 3d acceleration please? To overcome http://pastebin.com/raw.php?i=AwPnpSJ7 which you pasted on IRC, you need to compile Mesa with: --with-egl-platforms=drm -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH] xwayland: Activate and enable device on first capability reporting
Commit 2172714c changed behavior of capability handling, but it only
solved part of the problem. If Xwayland is launched without a capability
(e.g. no pointer device is connected when Xwayland was spinned up), and
later that capability comes, the device added will not be automatically
initialized. This patch initializes the device when the capability is
reported for the first time, thus avoiding the problem.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=81819
Signed-off-by: Boyan Ding stu_...@126.com
---
hw/xwayland/xwayland-input.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index cc5f7df..12c1bbc 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -496,13 +496,13 @@ seat_handle_capabilities(void *data, struct wl_seat *seat,
wl_pointer_add_listener(xwl_seat-wl_pointer,
pointer_listener, xwl_seat);
-if (xwl_seat-pointer)
-EnableDevice(xwl_seat-pointer, TRUE);
-else {
+if (xwl_seat-pointer == NULL) {
xwl_seat_set_cursor(xwl_seat);
xwl_seat-pointer =
add_device(xwl_seat, xwayland-pointer, xwl_pointer_proc);
+ActivateDevice(xwl_seat-pointer, TRUE);
}
+EnableDevice(xwl_seat-pointer, TRUE);
} else if (!(caps WL_SEAT_CAPABILITY_POINTER) xwl_seat-wl_pointer) {
wl_pointer_release(xwl_seat-wl_pointer);
xwl_seat-wl_pointer = NULL;
@@ -516,12 +516,12 @@ seat_handle_capabilities(void *data, struct wl_seat *seat,
wl_keyboard_add_listener(xwl_seat-wl_keyboard,
keyboard_listener, xwl_seat);
-if (xwl_seat-keyboard)
-EnableDevice(xwl_seat-keyboard, TRUE);
-else {
+if (xwl_seat-keyboard == NULL) {
xwl_seat-keyboard =
add_device(xwl_seat, xwayland-keyboard, xwl_keyboard_proc);
+ActivateDevice(xwl_seat-keyboard, TRUE);
}
+EnableDevice(xwl_seat-keyboard, TRUE);
} else if (!(caps WL_SEAT_CAPABILITY_KEYBOARD) xwl_seat-wl_keyboard)
{
wl_keyboard_release(xwl_seat-wl_keyboard);
xwl_seat-wl_keyboard = NULL;
--
2.0.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Update manpage with the proper location of system.twmrc file
Signed-off-by: Laurent Carlier lordhea...@gmail.com --- man/Makefile.am | 2 ++ man/twm.man | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/man/Makefile.am b/man/Makefile.am index 7d45968..f59d5b5 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -33,6 +33,8 @@ CLEANFILES = $(appman_DATA) SUFFIXES = .$(APP_MAN_SUFFIX) .man +MAN_SUBSTS += -e 's|__datadir__|$(datadir)|g' + # String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure .man.$(APP_MAN_SUFFIX): $(AM_V_GEN)$(SED) $(MAN_SUBSTS) $ $@ diff --git a/man/twm.man b/man/twm.man index cc8bc5f..d1dbaa0 100644 --- a/man/twm.man +++ b/man/twm.man @@ -132,7 +132,7 @@ differing visual types. .B $HOME/.twmrc This is the usual name for an individual user's startup file. .TP 8 -.B __projectroot__/lib/X11/twm/system.twmrc +.B __datadir__/X11/twm/system.twmrc If neither of the preceding files are found, \fItwm\fP will look in this file for a default configuration. This is often tailored by the site administrator to -- 2.0.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Update manpage with the proper location of system.twmrc file
Am 04.08.2014 16:39, schrieb Laurent Carlier: Signed-off-by: Laurent Carlier lordhea...@gmail.com --- man/Makefile.am | 2 ++ man/twm.man | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/man/Makefile.am b/man/Makefile.am index 7d45968..f59d5b5 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -33,6 +33,8 @@ CLEANFILES = $(appman_DATA) SUFFIXES = .$(APP_MAN_SUFFIX) .man +MAN_SUBSTS +=-e 's|__datadir__|$(datadir)|g' + I never noticed that one can use | as replacement for / in sed. Since the documentation of sed describes /, why | in this case ? re, wh # String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure .man.$(APP_MAN_SUFFIX): $(AM_V_GEN)$(SED) $(MAN_SUBSTS) $ $@ diff --git a/man/twm.man b/man/twm.man index cc8bc5f..d1dbaa0 100644 --- a/man/twm.man +++ b/man/twm.man @@ -132,7 +132,7 @@ differing visual types. .B $HOME/.twmrc This is the usual name for an individual user's startup file. .TP 8 -.B __projectroot__/lib/X11/twm/system.twmrc +.B __datadir__/X11/twm/system.twmrc If neither of the preceding files are found, \fItwm\fP will look in this file for a default configuration. This is often tailored by the site administrator to ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Update manpage with the proper location of system.twmrc file
On Mon, Aug 04, 2014 at 04:48:58PM +0200, walter harms wrote: Am 04.08.2014 16:39, schrieb Laurent Carlier: Signed-off-by: Laurent Carlier lordhea...@gmail.com --- man/Makefile.am | 2 ++ man/twm.man | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/man/Makefile.am b/man/Makefile.am index 7d45968..f59d5b5 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -33,6 +33,8 @@ CLEANFILES = $(appman_DATA) SUFFIXES = .$(APP_MAN_SUFFIX) .man +MAN_SUBSTS += -e 's|__datadir__|$(datadir)|g' + I never noticed that one can use | as replacement for / in sed. Since the documentation of sed describes /, why | in this case ? You can use any letter instead of '/'. '|' is often used when replacing paths, since it's not very common in them :) Thomas ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Update manpage with the proper location of system.twmrc file
On 08/ 4/14 08:36 AM, Thomas Klausner wrote: On Mon, Aug 04, 2014 at 04:48:58PM +0200, walter harms wrote: Am 04.08.2014 16:39, schrieb Laurent Carlier: Signed-off-by: Laurent Carlier lordhea...@gmail.com --- man/Makefile.am | 2 ++ man/twm.man | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/man/Makefile.am b/man/Makefile.am index 7d45968..f59d5b5 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -33,6 +33,8 @@ CLEANFILES = $(appman_DATA) SUFFIXES = .$(APP_MAN_SUFFIX) .man +MAN_SUBSTS += -e 's|__datadir__|$(datadir)|g' + I never noticed that one can use | as replacement for / in sed. Since the documentation of sed describes /, why | in this case ? You can use any letter instead of '/'. '|' is often used when replacing paths, since it's not very common in them :) Right - since this case is going to expand to a path containing / characters, using | avoids having to find some way to escape the / in $(datadir) when make substitutes it. '|' is used all over the X makefiles for pathname substitutions with sed for this reason, so this fits our style. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 03/12] Don't use GetScratchPixmapHeader for shadow pixmaps
Keith Packard kei...@keithp.com writes: Eric Anholt e...@anholt.net writes: This change appears to be unrelated, and possibly harmful (if X has dropped the last ref to the BO, but it's still the scanout buffer, a new allocation would now reuse the BO and scribble on scanout until the next modeset happens). Yeah, it's unrelated. intel_allocate_framebuffer calls disable_reuse, so there's no need to call it from these two other places. I'll split that change out into a separate patch with separate comment. Unrelated whitespace. There are a bunch of whitespace fixups; should I pull those into a separate patch or just leave them scattered in the first patch to change a file? One patch at the front is fine with me. pgpqjvDTUOs5x.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 01/12] Stop trying to out-guess mesa for BO allocation
Keith Packard kei...@keithp.com writes: Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: I don't see anything indicating that this code path is only used by glamor. True. It's a fix for DRI3 for either UXA or none. Mesa allocates a single page for a 1x1 texture, but this code thinks that should take two pages causing a texture-to-pixmap operation to fail. OK, but isn't the problem with the code you're #if 0ing (which, really? #if 0 in a patch being submitted for review?) that it's aligning to 2*height instead of height? pgp8Ngnh1wzPp.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] BellProc: Send bell event on core protocol bell when requested
XKB allows to override the BellProc() ringing the 'keyboard bell':
instead an event is sent to an X client which can perform an
appropriate action.
In most cases this effectively prevents the core protocol bell
from ringing: if no BellProc() is set for the device, no attempt
is made to ring a bell.
This patch ensures that an XKB bell event is sent also when
the core protocol bell is rung end thus an appropriate action
can be taken by a client.
Signed-off-by: Egbert Eich e...@freedesktop.org
---
dix/devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dix/devices.c b/dix/devices.c
index 7f079ff..5d26fae 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -2257,7 +2257,7 @@ ProcBell(ClientPtr client)
for (dev = inputInfo.devices; dev; dev = dev-next) {
if ((dev == keybd ||
(!IsMaster(dev) GetMaster(dev, MASTER_KEYBOARD) == keybd))
-dev-kbdfeed dev-kbdfeed-BellProc) {
+((dev-kbdfeed dev-kbdfeed-BellProc) || dev-xkb_interest)) {
rc = XaceHook(XACE_DEVICE_ACCESS, client, dev, DixBellAccess);
if (rc != Success)
--
1.8.4.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xkbcomp: Improved -w option parsing
This patch improves -w option parsing even further, for cases like
xkbcomp -w6 4.xkb out.xkb (which were not handled by the fix of
#66344). Moreover, though this form can be regarded as ambiguous,
the warning level is still optional (set to 0 if not present), and
errors like xkbcomp -wfoo in out are detected and reported.
Signed-off-by: Vincent Lefevre vinc...@vinc17.net
---
xkbcomp.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/xkbcomp.c b/xkbcomp.c
index 956e79c..1bb8ab2 100644
--- a/xkbcomp.c
+++ b/xkbcomp.c
@@ -576,17 +576,33 @@ parseArgs(int argc, char *argv[])
}
else if (strncmp(argv[i], -w, 2) == 0)
{
-if ((i = (argc - 1)) || (!isdigit(argv[i + 1][0])))
+unsigned long utmp;
+char *tmp2;
+/* If text is just after -w in the same word, then it must
+ * be a number and it is the warning level. Otherwise, if the
+ * next argument is a number, then it is the warning level,
+ * else the warning level is assumed to be 0.
+ */
+if (argv[i][2] == '\0')
{
warningLevel = 0;
-if (isdigit(argv[i][2]))
-if (sscanf(argv[i][2], %i, itmp) == 1)
-warningLevel = itmp;
+if (i argc - 1)
+{
+utmp = strtoul(argv[i+1], tmp2, 10);
+if (argv[i+1][0] != '\0' *tmp2 == '\0')
+{
+warningLevel = utmp 10 ? 10 : utmp;
+i++;
+}
+}
}
else
{
-if (sscanf(argv[++i], %i, itmp) == 1)
-warningLevel = itmp;
+utmp = strtoul(argv[i][2], tmp2, 10);
+if (*tmp2 == '\0')
+warningLevel = utmp 10 ? 10 : utmp;
+else
+goto unknown_flag;
}
}
else if ((strcmp(argv[i], -xkb) == 0) (!xkblist))
@@ -619,6 +635,7 @@ parseArgs(int argc, char *argv[])
}
else
{
+ unknown_flag:
ERROR1(Unknown flag \%s\ on command line\n, argv[i]);
Usage(argc, argv);
return False;
--
2.0.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] BellProc: Send bell event on core protocol bell when requested
On Mon, Aug 04, 2014 at 07:16:30PM +0200, Egbert Eich wrote:
XKB allows to override the BellProc() ringing the 'keyboard bell':
instead an event is sent to an X client which can perform an
appropriate action.
In most cases this effectively prevents the core protocol bell
from ringing: if no BellProc() is set for the device, no attempt
is made to ring a bell.
This patch ensures that an XKB bell event is sent also when
the core protocol bell is rung end thus an appropriate action
can be taken by a client.
Signed-off-by: Egbert Eich e...@freedesktop.org
Acked-by: Peter Hutterer peter.hutte...@who-t.net
Keith, can you merge this directly please? Thanks
Cheers,
Peter
---
dix/devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dix/devices.c b/dix/devices.c
index 7f079ff..5d26fae 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -2257,7 +2257,7 @@ ProcBell(ClientPtr client)
for (dev = inputInfo.devices; dev; dev = dev-next) {
if ((dev == keybd ||
(!IsMaster(dev) GetMaster(dev, MASTER_KEYBOARD) == keybd))
-dev-kbdfeed dev-kbdfeed-BellProc) {
+((dev-kbdfeed dev-kbdfeed-BellProc) || dev-xkb_interest))
{
rc = XaceHook(XACE_DEVICE_ACCESS, client, dev, DixBellAccess);
if (rc != Success)
--
1.8.4.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 01/12] Stop trying to out-guess mesa for BO allocation
Eric Anholt e...@anholt.net writes: OK, but isn't the problem with the code you're #if 0ing (which, really? #if 0 in a patch being submitted for review?) that it's aligning to 2*height instead of height? I went and did a bit of archaeology to figure out why it's using 2*height instead of just height. The initial change to pixmap allocation, which was then copied to the BO validation logic, was here: commit 736b89504a32239a0c7dfb5961c1b8292dd744bd Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sun Dec 30 10:32:18 2012 + uxa: Align surface allocations to even tile rows Align surface sizes to an even number of tile rows to cater for sampler prefetch. If we read beyond the last page we may catch the PTE in a state of flux and trigger a GPU hang. Also detected by enabling invalid PTE access checking. References: https://bugs.freedesktop.org/show_bug.cgi?id=56916 References: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk diff --git a/src/intel_uxa.c b/src/intel_uxa.c index f5ac0a6..2f14173 100644 --- a/src/intel_uxa.c +++ b/src/intel_uxa.c @@ -209,7 +209,7 @@ intel_uxa_pixmap_compute_size(PixmapPtr pixmap, tile_height = 8; else tile_height = 32; - aligned_h = ALIGN(h, tile_height); + aligned_h = ALIGN(h, 2*tile_height); *stride = intel_get_fence_pitch(intel, ALIGN(pitch, 512), Look at the referenced bugs, what I found was a long list of random GPU hangs on ILK and SNB hardware that appear to have been caused by a kernel change. Daniel and Chris created a number of scatter shot fixes across the kernel, and this patch to the 2D driver. However, this patch doesn't appear to have actually solved anything; Norbert Preining was still crashing with this patch applied: https://bugs.freedesktop.org/show_bug.cgi?id=55984#c129 Furthermore, SNA has some similar code, but it applies it conditionally for hardware which doesn't have 'relaxed fencing', which is only hardware older than i965 when running on a older kernel that doesn't recognize the HAS_RELAXED_FENCING parameter (the current kernel always returns 'true'). So, as near as I can tell, this fix should never be necessary as the reported bug wasn't fixed by it, and SNA does not apply this rule to any hardware on which either bug was reproduced. If this fix is actually useful, wouldn't we want it in Mesa as well? -- keith.pack...@intel.com pgp4Ev3h5OZTD.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] BellProc: Send bell event on core protocol bell when requested
Peter Hutterer peter.hutte...@who-t.net writes: Acked-by: Peter Hutterer peter.hutte...@who-t.net Keith, can you merge this directly please? Thanks Yup. Merged. e8373e4..e6c8c7e master - master -- keith.pack...@intel.com pgpZantoSPsxR.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[Bug 76213] xfce4 panel is not rendered properly on radeon southern islands
https://bugs.freedesktop.org/show_bug.cgi?id=76213 --- Comment #7 from Michel Dänzer mic...@daenzer.net --- Does this still happen with glamor from xserver 1.16.0 or later? -- You are receiving this mail because: You are the QA Contact for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 68524] radeonsi with glamor has very poor performance with primitives drawing
https://bugs.freedesktop.org/show_bug.cgi?id=68524 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #68 from Michel Dänzer mic...@daenzer.net --- glamor from xserver 1.16.0 or particularly from current xserver Git master has greatly improved performance. gtkperf completes in under 3 seconds for me. Any remaining issues should be tracked in separate reports. -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 63397] Screen corruption with LibreOffice/OpenOffice (with glamor enabled)
https://bugs.freedesktop.org/show_bug.cgi?id=63397 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Michel Dänzer mic...@daenzer.net --- I think this should be fixed, please reopen if it still happens with glamor from xserver 1.16.0 or later. -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52407] [GLAMOR][Zaphod] xserver segfaults on startup (with backtrace).
https://bugs.freedesktop.org/show_bug.cgi?id=52407 --- Comment #5 from Michel Dänzer mic...@daenzer.net --- Is this still an issue with xf86-video-ati 7.4.0 or later and glamor from xserver 1.16.0 or later? -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 1/4] radeon: drop redundant radeon_drm.h includes
Already included via radeon.h. Signed-off-by: Andreas Boll andreas.boll@gmail.com --- src/cayman_accel.c| 1 - src/drmmode_display.c | 1 - src/evergreen_accel.c | 1 - src/r6xx_accel.c | 1 - src/radeon_exa.c | 1 - 5 files changed, 5 deletions(-) diff --git a/src/cayman_accel.c b/src/cayman_accel.c index c1f74cb..a754610 100644 --- a/src/cayman_accel.c +++ b/src/cayman_accel.c @@ -36,7 +36,6 @@ #include cayman_reg.h #include evergreen_state.h -#include radeon_drm.h #include radeon_vbo.h #include radeon_exa_shared.h diff --git a/src/drmmode_display.c b/src/drmmode_display.c index c366203..ef5dfbe 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -36,7 +36,6 @@ #include xf86cmap.h #include radeon.h #include radeon_reg.h -#include radeon_drm.h #include sarea.h #include drmmode_display.h diff --git a/src/evergreen_accel.c b/src/evergreen_accel.c index 3a76a71..41ebc1a 100644 --- a/src/evergreen_accel.c +++ b/src/evergreen_accel.c @@ -37,7 +37,6 @@ #include evergreen_reg.h #include evergreen_state.h -#include radeon_drm.h #include radeon_vbo.h #include radeon_exa_shared.h diff --git a/src/r6xx_accel.c b/src/r6xx_accel.c index 6bbf663..a97c84b 100644 --- a/src/r6xx_accel.c +++ b/src/r6xx_accel.c @@ -37,7 +37,6 @@ #include r600_reg.h #include r600_state.h -#include radeon_drm.h #include radeon_vbo.h #include radeon_exa_shared.h diff --git a/src/radeon_exa.c b/src/radeon_exa.c index cf368d5..0d6cd24 100644 --- a/src/radeon_exa.c +++ b/src/radeon_exa.c @@ -36,7 +36,6 @@ #include radeon.h #include radeon_reg.h #include r600_reg.h -#include radeon_drm.h #include radeon_bo_helper.h #include radeon_probe.h #include radeon_version.h -- 2.0.1 ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 2/4] radeon: move RADEON_TILING_{MASK, LINEAR} from radeon_drm.h to radeon.h
This allows us to drop radeon_drm.h from xf86-video-ati and use instead
radeon_drm.h from libdrm.
Signed-off-by: Andreas Boll andreas.boll@gmail.com
---
src/radeon.h | 2 ++
src/radeon_drm.h | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/radeon.h b/src/radeon.h
index eac6ed5..6123cc2 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -820,5 +820,7 @@ RADEONLog2(int val)
#endif
}
+#define RADEON_TILING_MASK 0xff
+#define RADEON_TILING_LINEAR 0x0
#endif /* _RADEON_H_ */
diff --git a/src/radeon_drm.h b/src/radeon_drm.h
index 2bbd8fa..042e822 100644
--- a/src/radeon_drm.h
+++ b/src/radeon_drm.h
@@ -800,8 +800,6 @@ struct drm_radeon_gem_create {
uint32_tflags;
};
-#define RADEON_TILING_MASK 0xff
-#define RADEON_TILING_LINEAR 0x0
#define RADEON_TILING_MACRO0x1
#define RADEON_TILING_MICRO0x2
#define RADEON_TILING_SWAP_16BIT 0x4
--
2.0.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 3/4] radeon: drop radeon_drm.h
Now we use libdrm's radeon_drm.h. Signed-off-by: Andreas Boll andreas.boll@gmail.com --- src/Makefile.am | 1 - src/radeon_drm.h | 918 --- 2 files changed, 919 deletions(-) delete mode 100644 src/radeon_drm.h diff --git a/src/Makefile.am b/src/Makefile.am index e23dc1d..9ff1ffb 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -88,7 +88,6 @@ EXTRA_DIST = \ bicubic_table.h \ bicubic_table.py \ radeon_bo_helper.h \ - radeon_drm.h \ radeon_exa_render.c \ radeon_exa_funcs.c \ radeon_exa_shared.h \ diff --git a/src/radeon_drm.h b/src/radeon_drm.h deleted file mode 100644 index 042e822..000 --- a/src/radeon_drm.h +++ /dev/null @@ -1,918 +0,0 @@ -/* radeon_drm.h -- Public header for the radeon driver -*- linux-c -*- - * - * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas. - * Copyright 2000 VA Linux Systems, Inc., Fremont, California. - * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas. - * All rights reserved. - * - * Permission is hereby granted, free of charge, to any person obtaining a - * copy of this software and associated documentation files (the Software), - * to deal in the Software without restriction, including without limitation - * the rights to use, copy, modify, merge, publish, distribute, sublicense, - * and/or sell copies of the Software, and to permit persons to whom the - * Software is furnished to do so, subject to the following conditions: - * - * The above copyright notice and this permission notice (including the next - * paragraph) shall be included in all copies or substantial portions of the - * Software. - * - * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL - * PRECISION INSIGHT AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER - * DEALINGS IN THE SOFTWARE. - * - * Authors: - *Kevin E. Martin mar...@valinux.com - *Gareth Hughes gar...@valinux.com - *Keith Whitwell ke...@tungstengraphics.com - */ - -#ifndef __RADEON_DRM_H__ -#define __RADEON_DRM_H__ - -/* WARNING: If you change any of these defines, make sure to change the - * defines in the X server file (radeon_sarea.h) - */ -#ifndef __RADEON_SAREA_DEFINES__ -#define __RADEON_SAREA_DEFINES__ - -/* Old style state flags, required for sarea interface (1.1 and 1.2 - * clears) and 1.2 drm_vertex2 ioctl. - */ -#define RADEON_UPLOAD_CONTEXT 0x0001 -#define RADEON_UPLOAD_VERTFMT 0x0002 -#define RADEON_UPLOAD_LINE 0x0004 -#define RADEON_UPLOAD_BUMPMAP 0x0008 -#define RADEON_UPLOAD_MASKS0x0010 -#define RADEON_UPLOAD_VIEWPORT 0x0020 -#define RADEON_UPLOAD_SETUP0x0040 -#define RADEON_UPLOAD_TCL 0x0080 -#define RADEON_UPLOAD_MISC 0x0100 -#define RADEON_UPLOAD_TEX0 0x0200 -#define RADEON_UPLOAD_TEX1 0x0400 -#define RADEON_UPLOAD_TEX2 0x0800 -#define RADEON_UPLOAD_TEX0IMAGES 0x1000 -#define RADEON_UPLOAD_TEX1IMAGES 0x2000 -#define RADEON_UPLOAD_TEX2IMAGES 0x4000 -#define RADEON_UPLOAD_CLIPRECTS0x8000 /* handled client-side */ -#define RADEON_REQUIRE_QUIESCENCE 0x0001 -#define RADEON_UPLOAD_ZBIAS0x0002 /* version 1.2 and newer */ -#define RADEON_UPLOAD_ALL 0x003e -#define RADEON_UPLOAD_CONTEXT_ALL 0x003e01ff - -/* New style per-packet identifiers for use in cmd_buffer ioctl with - * the RADEON_EMIT_PACKET command. Comments relate new packets to old - * state bits and the packet size: - */ -#define RADEON_EMIT_PP_MISC 0 /* context/7 */ -#define RADEON_EMIT_PP_CNTL 1 /* context/3 */ -#define RADEON_EMIT_RB3D_COLORPITCH 2 /* context/1 */ -#define RADEON_EMIT_RE_LINE_PATTERN 3 /* line/2 */ -#define RADEON_EMIT_SE_LINE_WIDTH 4 /* line/1 */ -#define RADEON_EMIT_PP_LUM_MATRIX 5 /* bumpmap/1 */ -#define RADEON_EMIT_PP_ROT_MATRIX_0 6 /* bumpmap/2 */ -#define RADEON_EMIT_RB3D_STENCILREFMASK 7 /* masks/3 */ -#define RADEON_EMIT_SE_VPORT_XSCALE 8 /* viewport/6 */ -#define RADEON_EMIT_SE_CNTL 9 /* setup/2 */ -#define RADEON_EMIT_SE_CNTL_STATUS 10 /* setup/1 */ -#define RADEON_EMIT_RE_MISC 11 /* misc/1 */ -#define RADEON_EMIT_PP_TXFILTER_0 12 /* tex0/6 */ -#define RADEON_EMIT_PP_BORDER_COLOR_0 13 /* tex0/1 */ -#define
[PATCH 4/4] radeon: remove definitions already present in radeon_drm.h
Signed-off-by: Andreas Boll andreas.boll@gmail.com --- src/radeon_kms.c | 17 - 1 file changed, 17 deletions(-) diff --git a/src/radeon_kms.c b/src/radeon_kms.c index b92ae90..171d919 100644 --- a/src/radeon_kms.c +++ b/src/radeon_kms.c @@ -333,9 +333,6 @@ static Bool RADEONIsFastFBWorking(ScrnInfoPtr pScrn) int r; uint32_t tmp = 0; -#ifndef RADEON_INFO_FASTFB_WORKING -#define RADEON_INFO_FASTFB_WORKING 0x14 -#endif memset(ginfo, 0, sizeof(ginfo)); ginfo.request = RADEON_INFO_FASTFB_WORKING; ginfo.value = (uintptr_t)tmp; @@ -355,9 +352,6 @@ static Bool RADEONIsFusionGARTWorking(ScrnInfoPtr pScrn) int r; uint32_t tmp; -#ifndef RADEON_INFO_FUSION_GART_WORKING -#define RADEON_INFO_FUSION_GART_WORKING 0x0c -#endif memset(ginfo, 0, sizeof(ginfo)); ginfo.request = RADEON_INFO_FUSION_GART_WORKING; ginfo.value = (uintptr_t)tmp; @@ -377,13 +371,6 @@ static Bool RADEONIsAccelWorking(ScrnInfoPtr pScrn) int r; uint32_t tmp; -#ifndef RADEON_INFO_ACCEL_WORKING -#define RADEON_INFO_ACCEL_WORKING 0x03 -#endif -#ifndef RADEON_INFO_ACCEL_WORKING2 -#define RADEON_INFO_ACCEL_WORKING2 0x05 -#endif - memset(ginfo, 0, sizeof(ginfo)); if (info-dri2.pKernelDRMVersion-version_minor = 5) ginfo.request = RADEON_INFO_ACCEL_WORKING2; @@ -683,10 +670,6 @@ static Bool r600_get_tile_config(ScrnInfoPtr pScrn) if (info-ChipFamily CHIP_FAMILY_R600) return FALSE; -#ifndef RADEON_INFO_TILING_CONFIG -#define RADEON_INFO_TILING_CONFIG 0x6 -#endif - memset(ginfo, 0, sizeof(ginfo)); ginfo.request = RADEON_INFO_TILING_CONFIG; ginfo.value = (uintptr_t)tmp; -- 2.0.1 ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 0/4] radeon_drm.h cleanup
Hi,
while working with RADEON_INFO_ACCEL_WORKING2 I noticed that we use another
outdated copy of radeon_drm.h in xf86-video-ati.
Let's use radeon_drm.h from libdrm and drop this one.
Andreas.
Andreas Boll (4):
radeon: drop redundant radeon_drm.h includes
radeon: move RADEON_TILING_{MASK,LINEAR} from radeon_drm.h to radeon.h
radeon: drop radeon_drm.h
radeon: remove definitions already present in radeon_drm.h
src/Makefile.am | 1 -
src/cayman_accel.c| 1 -
src/drmmode_display.c | 1 -
src/evergreen_accel.c | 1 -
src/r6xx_accel.c | 1 -
src/radeon.h | 2 +
src/radeon_drm.h | 920 --
src/radeon_exa.c | 1 -
src/radeon_kms.c | 17 -
9 files changed, 2 insertions(+), 943 deletions(-)
delete mode 100644 src/radeon_drm.h
--
2.0.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 82140] New: Glamor: Extremely slow display of Xfce logout dialog
https://bugs.freedesktop.org/show_bug.cgi?id=82140 Priority: medium Bug ID: 82140 Assignee: xorg-driver-ati@lists.x.org Summary: Glamor: Extremely slow display of Xfce logout dialog QA Contact: xorg-t...@lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: i...@noctus.net Hardware: x86-64 (AMD64) Status: NEW Version: 7.4 (2008.09) Component: Driver/Radeon Product: xorg Trying to open the Xfce logout dialog takes 39 -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 82140] Glamor: extremely slow display of Xfce logout dialog
https://bugs.freedesktop.org/show_bug.cgi?id=82140 Mathias Brodala i...@noctus.net changed: What|Removed |Added Summary|Glamor: Extremely slow |Glamor: extremely slow |display of Xfce logout |display of Xfce logout |dialog |dialog -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 82140] Glamor: extremely slow display of Xfce logout dialog
https://bugs.freedesktop.org/show_bug.cgi?id=82140 Mathias Brodala i...@noctus.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mathias Brodala i...@noctus.net --- I hit the return key while editing the subject. :-/ I'll add a new report. -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 76213] xfce4 panel is not rendered properly on radeon southern islands
https://bugs.freedesktop.org/show_bug.cgi?id=76213 --- Comment #8 from Sylvain BERTRAND sylvain.bertr...@gmail.com --- up-to-date fedora rawhide with Xorg server 1.16.0 and linux kernel 3.16.0 (recent mesa and llvm) Still wrongly rendered. -- You are receiving this mail because: You are the QA Contact for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 0/4] radeon_drm.h cleanup
On Mon, Aug 4, 2014 at 10:23 AM, Andreas Boll
andreas.boll@gmail.com wrote:
Hi,
while working with RADEON_INFO_ACCEL_WORKING2 I noticed that we use another
outdated copy of radeon_drm.h in xf86-video-ati.
Let's use radeon_drm.h from libdrm and drop this one.
Series is:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
Andreas.
Andreas Boll (4):
radeon: drop redundant radeon_drm.h includes
radeon: move RADEON_TILING_{MASK,LINEAR} from radeon_drm.h to radeon.h
radeon: drop radeon_drm.h
radeon: remove definitions already present in radeon_drm.h
src/Makefile.am | 1 -
src/cayman_accel.c| 1 -
src/drmmode_display.c | 1 -
src/evergreen_accel.c | 1 -
src/r6xx_accel.c | 1 -
src/radeon.h | 2 +
src/radeon_drm.h | 920
--
src/radeon_exa.c | 1 -
src/radeon_kms.c | 17 -
9 files changed, 2 insertions(+), 943 deletions(-)
delete mode 100644 src/radeon_drm.h
--
2.0.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH r128] Improve handling of monitor and output types
Checking for OUTPUT_DVI is not the same as checking for MT_DFP. There
might be r128 cards with a DVI-I connector. These have the capability of
driving an MT_CRT so we now check the monitor type before programming
DAC or TMDS registers.
This patch also removes R128ConnectorType and R128BIOSConnector because
they were not doing much. These data structures are more useful for the
radeon driver where there is a much wider range of cards.
Signed-off-by: Connor Behan connor.be...@gmail.com
---
src/r128.h| 1 -
src/r128_driver.c | 2 +-
src/r128_output.c | 160 --
src/r128_probe.h | 16 --
4 files changed, 60 insertions(+), 119 deletions(-)
diff --git a/src/r128.h b/src/r128.h
index 6df1b51..d8748b7 100644
--- a/src/r128.h
+++ b/src/r128.h
@@ -504,7 +504,6 @@ typedef struct {
Bool DDC;
Bool VGAAccess;
-R128BIOSConnector BiosConnector[R128_MAX_BIOS_CONNECTOR];
/** Added for dualhead support ***/
BOOL IsSecondary; /* second Screen */
diff --git a/src/r128_driver.c b/src/r128_driver.c
index c541bfa..ce38b4e 100644
--- a/src/r128_driver.c
+++ b/src/r128_driver.c
@@ -3225,7 +3225,7 @@ void R128InitRMXRegisters(R128SavePtr orig, R128SavePtr
save,
save-fp_h_sync_strt_wid = save-crtc_h_sync_strt_wid;
save-fp_v_sync_strt_wid = save-crtc_v_sync_strt_wid;
-if (r128_output-type != OUTPUT_DVI r128_output-type != OUTPUT_LVDS)
+if (r128_output-MonType != MT_DFP r128_output-MonType != MT_LCD)
return;
if (r128_output-PanelXRes == 0 || r128_output-PanelYRes == 0) {
diff --git a/src/r128_output.c b/src/r128_output.c
index 7bb2e2a..757ef9b 100644
--- a/src/r128_output.c
+++ b/src/r128_output.c
@@ -90,21 +90,21 @@ static void r128_mode_set(xf86OutputPtr output,
DisplayModePtr mode, DisplayMode
if (r128_crtc-crtc_id == 0)
R128InitRMXRegisters(info-SavedReg, info-ModeReg, output,
adjusted_mode);
-if (r128_output-type == OUTPUT_DVI)
+if (r128_output-MonType == MT_DFP)
R128InitFPRegisters(info-SavedReg, info-ModeReg, output);
-else if (r128_output-type == OUTPUT_LVDS)
+else if (r128_output-MonType == MT_LCD)
R128InitLVDSRegisters(info-SavedReg, info-ModeReg, output);
-else if (r128_output-type == OUTPUT_VGA)
+else if (r128_output-MonType == MT_CRT)
R128InitDACRegisters(info-SavedReg, info-ModeReg, output);
if (r128_crtc-crtc_id == 0)
R128RestoreRMXRegisters(pScrn, info-ModeReg);
-if (r128_output-type == OUTPUT_DVI)
+if (r128_output-MonType == MT_DFP)
R128RestoreFPRegisters(pScrn, info-ModeReg);
-else if (r128_output-type == OUTPUT_LVDS)
+else if (r128_output-MonType == MT_LCD)
R128RestoreLVDSRegisters(pScrn, info-ModeReg);
-else if (r128_output-type == OUTPUT_VGA)
+else if (r128_output-MonType == MT_CRT)
R128RestoreDACRegisters(pScrn, info-ModeReg);
}
@@ -375,133 +375,91 @@ static Bool R128I2CInit(xf86OutputPtr output, I2CBusPtr
*bus_ptr, char *name)
return TRUE;
}
-void R128SetOutputType(ScrnInfoPtr pScrn, R128OutputPrivatePtr r128_output)
-{
-R128OutputType output = OUTPUT_NONE;
-
-switch (r128_output-ConnectorType) {
-case CONNECTOR_VGA:
-output = OUTPUT_VGA;
-break;
-case CONNECTOR_LVDS:
-output = OUTPUT_LVDS;
-break;
-case CONNECTOR_DVI_D:
-case CONNECTOR_DVI_I:
-case CONNECTOR_DVI_A:
-output = OUTPUT_DVI;
-break;
-default:
-output = OUTPUT_NONE;
-}
-
-r128_output-type = output;
-}
-
-void R128SetupGenericConnectors(ScrnInfoPtr pScrn)
+void R128SetupGenericConnectors(ScrnInfoPtr pScrn, R128OutputType *otypes)
{
R128InfoPtr info= R128PTR(pScrn);
R128EntPtr pR128Ent = R128EntPriv(pScrn);
if (!pR128Ent-HasCRTC2 !info-isDFP) {
-info-BiosConnector[0].ConnectorType = CONNECTOR_VGA;
-info-BiosConnector[0].valid = TRUE;
+otypes[0] = OUTPUT_VGA;
return;
} else if (!pR128Ent-HasCRTC2) {
-info-BiosConnector[0].ConnectorType = CONNECTOR_DVI_D;
- info-BiosConnector[0].valid = TRUE;
+otypes[0] = OUTPUT_DVI;
return;
}
-info-BiosConnector[0].ConnectorType = CONNECTOR_LVDS;
-info-BiosConnector[0].valid = TRUE;
-
-info-BiosConnector[1].ConnectorType = CONNECTOR_VGA;
-info-BiosConnector[1].valid = TRUE;
+otypes[0] = OUTPUT_LVDS;
+otypes[1] = OUTPUT_VGA;
}
Bool R128SetupConnectors(ScrnInfoPtr pScrn)
{
R128InfoPtr info= R128PTR(pScrn);
R128EntPtr pR128Ent = R128EntPriv(pScrn);
-xf86OutputPtr output;
+
+R128OutputType otypes[R128_MAX_BIOS_CONNECTOR];
+xf86OutputPtr output;
int num_vga = 0;
int num_dvi = 0;
int i;
-for (i = 0; i R128_MAX_BIOS_CONNECTOR; i++) {
-info-BiosConnector[i].valid = FALSE;
-
Bug#756848: xserver-xorg-video-radeon: Random segfaults with glamor enabled on Southern Islands card
Package: xserver-xorg-video-radeon Version: 1:7.4.0-2 Severity: important -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jul 19 2013 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2356320 Jul 17 18:25 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850] [1002:6819] /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.14-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-21) ) #1 SMP Debian 3.14.2-1 (2014-04-28) Xorg X server log files on system: -- -rw-r--r-- 1 root root 55494 Aug 2 09:01 /var/log/Xorg.0.log Contents of previous Xorg X server log file (/var/log/Xorg.0.log.old): - [ 37166.444] X.Org X Server 1.16.0 Release Date: 2014-07-16 [ 37166.444] X Protocol Version 11, Revision 0 [ 37166.444] Build Operating System: Linux 3.14-1-amd64 x86_64 Debian [ 37166.444] Current Operating System: Linux nebula 3.14-1-amd64 #1 SMP Debian 3.14.2-1 (2014-04-28) x86_64 [ 37166.444] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 root=UUID=10f3f61b-ebec-461b-8c72-94ba1cbcc165 ro quiet [ 37166.444] Build Date: 17 July 2014 10:22:36PM [ 37166.444] xorg-server 2:1.16.0-1 (http://www.debian.org/support) [ 37166.444] Current version of pixman: 0.32.4 [ 37166.444]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 37166.444] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 37166.444] (==) Log file: /var/log/Xorg.0.log, Time: Sat Aug 2 09:00:49 2014 [ 37166.445] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 37166.445] (==) No Layout section. Using the first Screen section. [ 37166.445] (==) No screen section available. Using defaults. [ 37166.445] (**) |--Screen Default Screen Section (0) [ 37166.445] (**) | |--Monitor default monitor [ 37166.445] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [ 37166.445] (==) Automatically adding devices [ 37166.445] (==) Automatically enabling devices [ 37166.445] (==) Automatically adding GPU devices [ 37166.445] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [ 37166.445]Entry deleted from font path. [ 37166.445] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1,
[Bug 82141] Glamor: extremely slow display of Xfce logout dialog
https://bugs.freedesktop.org/show_bug.cgi?id=82141 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Michel Dänzer mic...@daenzer.net --- *** This bug has been marked as a duplicate of bug 76285 *** -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
