[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #23 from Vova --- Same problem on HD 7420G. After s2ram display doesn`t wake up, but system work fine. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/f6596936/attachment.html>
[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #24 from Vova --- if via ssh try to start X, in dmesg see that: [ 236.672326] [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed [ 236.672327] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/75d73f6a/attachment.html>
[Bug 71697] New: [radeonsi] gtkperf hangs the system
https://bugs.freedesktop.org/show_bug.cgi?id=71697 Priority: medium Bug ID: 71697 Assignee: dri-devel at lists.freedesktop.org Summary: [radeonsi] gtkperf hangs the system Severity: normal Classification: Unclassified OS: All Reporter: darkbasic at linuxsystems.it Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI HD 7950 drm-next-3.13 (agd5f tree) libdrm git mesa git xf86-video-ati git xorg-server-1.14.4 + DRI-loader-entrypoint glamor git llvm 3.4 git The system hangs about a minute after gtkperf started, there is nothing in /var/log/messages. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/d5e99bc8/attachment.html>
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #40 from darkbasic --- gtkperf doesn't work at all for me: https://bugs.freedesktop.org/show_bug.cgi?id=71697 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/4b150a03/attachment.html>
[Bug 71697] [radeonsi] gtkperf hangs the system
https://bugs.freedesktop.org/show_bug.cgi?id=71697 --- Comment #1 from darkbasic --- It is a regression because it used to work, not in the kernel becuase 3.12 still hangs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/64e4810d/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #51 from Peter Fr?hberger --- Sorry, to warm up this thread. I have also seen that 24p playback is now "working" again. If one measure the audio vs the video clock. One is approx 10ms behind per 6 seconds, which is compensated by "Duplicating package" or "resampling" if your player supports this. On 50hz I am 10ms too far ahead per 6 seconds. This cause for example LiveTV to run out of packages. I compared every register with fglrx I could find and there is no real difference between those two. Log example with xbmc syncing to video clock (50hz): 15:15:58 T:139930428761856 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available 15:16:04 T:139930428761856 WARNING: Previous line repeats 6 times. 15:16:04 T:139930428761856 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:53826205859.132309, should be:53826216146.139511, error:10287.007199 15:16:04 T:139930428761856 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available 15:16:10 T:139930428761856 WARNING: Previous line repeats 10 times. 15:16:10 T:139930428761856 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:53832387675.043510, should be:53832398035.209015, error:10360.165502 15:16:12 T:139930428761856 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available 15:16:17 T:139930428761856 WARNING: Previous line repeats 7 times. 15:16:17 T:139930428761856 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:53838568755.002014, should be:53838579138.448776, error:10383.446764 15:16:17 T:139930428761856 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available 15:16:23 T:139930428761856 WARNING: Previous line repeats 16 times. 15:16:23 T:139930428761856 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:53844735030.241776, should be:53844745675.325325, error:10645.083549 15:16:23 T:139930428761856 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available Log with 24p: 12:00:37 T:140730861328128 DEBUG: CDVDPlayerAudio::Discontinuity2 - was:246782652.089114, should be:246769963.622166, error:-12688.466948 12:00:45 T:140730861328128 DEBUG: CDVDPlayerAudio::Discontinuity2 - was:254909959.765166, should be:254897679.533340, error:-12280.231826 12:00:53 T:140730861328128 DEBUG: CDVDPlayerAudio::Discontinuity2 - was:263037680.565340, should be:263025287.637961, I tried to play with register 0x05b4 and 0x05b8 but could not find a ratio so that the drops would stop. Not sure if this is related to the original problem though. Btw. you won't notice this problem, if you play local content and for example resample audio. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/89210f17/attachment-0001.html>
[Bug 71697] [radeonsi] gtkperf hangs the system
https://bugs.freedesktop.org/show_bug.cgi?id=71697 --- Comment #2 from Alex Deucher --- Can you narrow down which component (kernel, mesa, llvm, etc.) update caused the problem? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/0d878ebb/attachment.html>
[Bug 71697] [radeonsi] gtkperf hangs the system
https://bugs.freedesktop.org/show_bug.cgi?id=71697 --- Comment #3 from darkbasic --- It will not be that easy.. I don't use gtkperf since a few time and every single component of my graphic stack is pulled from git master. I recompiled kernel 3.12 which doesn't work but maybe the working one was 3.11, I tried downgrading glamor but X didn't start at all, maybe I needed to recompile xf86-video-ati. It's a time consuming process, being able to enable some kind of debug to have some hints would be preferable. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/e4538726/attachment.html>
[Bug 71697] [radeonsi] gtkperf hangs the system
https://bugs.freedesktop.org/show_bug.cgi?id=71697 --- Comment #4 from Thue Janus Kristensen --- It is probably the "GtkDrawingArea - Lines" component. The same problem is described in bug 68524. It is caused by the glamor software fallback being extremely slow. And obviously somehow mostly excluding other drawing operations. On my system, it doesn't crash the system, it only makes it extremely slow to respond. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/20324cbd/attachment.html>
[Bug 71697] [radeonsi] gtkperf hangs the system
https://bugs.freedesktop.org/show_bug.cgi?id=71697 --- Comment #5 from darkbasic --- So slow that it doesn't even switch to a virtual terminal with CTRL+ALT+F1? I checked some of the tests I did in the past with 3.12-pre-rc1 and I didn't do the total time test (the one which currently hangs): http://openbenchmarking.org/result/1309135-SO-2D744911973 I was pretty sure I did it in the past, but considering I don't find a benchmark of the total time I assume to be wrong. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/ab1b3665/attachment.html>
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #18 from Elven Decker --- I installed gdm and it works fine. I'm happy to help you debug this, but if you have more urgent requests, please feel free to ignore this. Thank you for helping me pin this down. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/4b2b2991/attachment.html>
[Bug 71516] [SOLVED] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 Elven Decker changed: What|Removed |Added Summary|RV350 Radeon 9550 - no |[SOLVED] RV350 Radeon 9550 |Unity 3D hardware support |- no Unity 3D hardware |in Ubuntu 13.10, extremely |support in Ubuntu 13.10, |slow|extremely slow -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/3fe455c4/attachment.html>
[PATCH] drm: Don't split up debug output
Otherwise we risk that the 2nd part of the line ends up on a line of
it's own, which means a kernel dmesg line without a log level. This
then upsets the dmesg checker in piglit.
Only really happens in some of the truly nasty igt testcases which
race cache dropping (through debugfs) with other gem operations.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_stub.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index f53d5246979c..74e0357c1c38 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -99,13 +99,19 @@ void drm_ut_debug_printk(unsigned int request_level,
const char *function_name,
const char *format, ...)
{
+ struct va_format vaf;
va_list args;
if (drm_debug & request_level) {
- if (function_name)
- printk(KERN_DEBUG "[%s:%s], ", prefix, function_name);
va_start(args, format);
- vprintk(format, args);
+ vaf.fmt = format;
+ vaf.va = &args;
+
+ if (function_name)
+ printk(KERN_DEBUG "[%s:%s], %pV", prefix,
+ function_name, &vaf);
+ else
+ printk(KERN_DEBUG "%pV", &vaf);
va_end(args);
}
}
--
1.8.1.4
possible regression Radeon RV280 (R3xx/R4xx ?) card freeze, re-apply old patch ?
n :00:10.0: Invalid ROM contents [2.761347] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM [2.761368] [drm] Using device-tree clock info [2.761398] [drm] AGP mode requested: 1 [2.761502] agpgart-uninorth :00:0b.0: putting AGP V2 device into 1x mode [2.761510] radeon :00:10.0: putting AGP V2 device into 1x mode [2.763545] radeon :00:10.0: GTT: 256M 0x - 0x0FFF [2.763576] [drm] Generation 2 PCI interface, using max accessible memory [2.763583] radeon :00:10.0: RADEON_CONFIG_APER_0_BASE: 0x98009800 (my message) [2.763590] radeon :00:10.0: VRAM: 128M 0x9800 - 0x9FFF (64M used) [2.763595] radeon :00:10.0: GTT in radeon_vram_location: 256M 0x - 0x0FFF (my message) [2.763697] [drm] Detected VRAM RAM=128M, BAR=128M [2.763702] [drm] RAM width 64bits DDR [2.766293] [TTM] Zone kernel: Available graphics memory: 381972 kiB [2.766299] [TTM] Zone highmem: Available graphics memory: 513044 kiB [2.766303] [TTM] Initializing pool allocator [2.766313] [TTM] Initializing DMA pool allocator [2.766405] [drm] radeon: 64M of VRAM memory ready [2.766499] [drm] radeon: 256M of GTT memory ready. [2.766655] [drm] radeon: ib pool ready. ... [2.876427] [drm] fence driver on ring 0 use gpu addr 0x and cpu addr 0xf137c000 [2.876435] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.876439] [drm] Driver supports precise vblank timestamp query. [2.876472] [drm] radeon: irq initialized. [2.877451] [drm] Loading R200 Microcode [2.884498] [drm] radeon: ring at 0x1000 [2.884572] [drm] ring test succeeded in 1 usecs [2.885156] [drm] ib test succeeded in 0 usecs i'm not certain whether gpu addr 0 is okay for the fence driver or whether the gtt location is okay (according to the comment in radeon_gtt_location it should be placed before or after VRAM) In PCI mode it ends at 0x97FF and VRAM starts directly after at 0x9800. In AGP mode GTT and VRAM are completely unrelated. Other than that it looks like the alignment thing isn't the problem. Cheers Jochen -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/2db18569/attachment.html>
[PATCH] Don't use libudev for glx/dri3
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard
---
configure.ac | 5 +--
src/glx/dri3_common.c | 106 +++---
2 files changed, 94 insertions(+), 17 deletions(-)
diff --git a/configure.ac b/configure.ac
index 63c2973..10e9e0f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -821,7 +821,6 @@ xyesno)
GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >=
$PRESENTPROTO_REQUIRED])
-PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED])
fi
# find the DRI deps for libGL
@@ -835,8 +834,8 @@ xyesno)
PKG_CHECK_MODULES([DRIGL], [$dri_modules])
GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV $dri_modules"
-X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS"
-GL_LIB_DEPS="$DRIGL_LIBS $LIBUDEV_LIBS"
+X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
+GL_LIB_DEPS="$DRIGL_LIBS"
# need DRM libs, $PTHREAD_LIBS, etc.
GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
index c758f96..01c9d09 100644
--- a/src/glx/dri3_common.c
+++ b/src/glx/dri3_common.c
@@ -72,22 +72,41 @@
#include "dri3_priv.h"
#define DRIVER_MAP_DRI3_ONLY
+
#include "pci_ids/pci_id_driver_map.h"
+static dev_t
+dri3_rdev_from_fd(int fd)
+{
+ struct stat buf;
+
+ if (fstat(fd, &buf) < 0) {
+ ErrorMessageF("DRI3: failed to stat fd %d", fd);
+ return 0;
+ }
+ return buf.st_rdev;
+}
+
+/*
+ * There are multiple udev library versions, and they aren't polite about
+ * symbols, so just avoid using it until some glorious future when the udev
+ * developers figure out how to not break things
+ */
+
+#define USE_UDEV 0
+#if USE_UDEV
#include
static struct udev_device *
dri3_udev_device_new_from_fd(struct udev *udev, int fd)
{
struct udev_device *device;
- struct stat buf;
+ dev_t rdev = dri3_rdev_from_fd(fd);
- if (fstat(fd, &buf) < 0) {
- ErrorMessageF("DRI3: failed to stat fd %d", fd);
+ if (rdev == 0)
return NULL;
- }
- device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
+ device = udev_device_new_from_devnum(udev, 'c', rdev);
if (device == NULL) {
ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
return NULL;
@@ -96,19 +115,20 @@ dri3_udev_device_new_from_fd(struct udev *udev, int fd)
return device;
}
-char *
-dri3_get_driver_for_fd(int fd)
+static int
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
{
struct udev *udev;
struct udev_device *device, *parent;
const char *pci_id;
- char *driver = NULL;
- int vendor_id, chip_id, i, j;
+ int ret = 0;
udev = udev_new();
+ if (!udev)
+ goto no_udev;
device = dri3_udev_device_new_from_fd(udev, fd);
if (device == NULL)
- return NULL;
+ goto no_dev;
parent = udev_device_get_parent(device);
if (parent == NULL) {
@@ -118,10 +138,71 @@ dri3_get_driver_for_fd(int fd)
pci_id = udev_device_get_property_value(parent, "PCI_ID");
if (pci_id == NULL ||
- sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
+ sscanf(pci_id, "%x:%x", vendorp, chipp) != 2) {
ErrorMessageF("DRI3: malformed or no PCI ID");
goto out;
}
+ ret = 1;
+
+out:
+ udev_device_unref(device);
+no_dev:
+ udev_unref(udev);
+no_udev:
+ return ret;
+}
+#else
+
+#define SYS_PATH_MAX256
+
+static int
+dri3_read_hex(dev_t rdev, char *entry, int *value)
+{
+ char path[SYS_PATH_MAX];
+ FILE *f;
+ int r;
+
+ snprintf(path, sizeof (path), "/sys/dev/char/%u:%u/device/%s",
+major(rdev), minor(rdev), entry);
+
+ printf ("path %s\n", path);
+
+ f = fopen(path,"r");
+ if (f == NULL)
+ return 0;
+
+ r = fscanf(f, "0x%x\n", value);
+ fclose(f);
+ if (r != 1)
+ return 0;
+ return 1;
+}
+
+static int
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
+{
+ dev_trdev = dri3_rdev_from_fd(fd);
+
+ if (!rdev)
+ return 0;
+
+ if (!dri3_read_hex(rdev, "vendor", vendorp))
+ return 0;
+ if (!dri3_read_hex(rdev, "device", chipp))
+ return 0;
+ return 1;
+}
+
+#endif
+
+char *
+dri3_get_driver_for_fd(int fd)
+{
+ char *driver = NULL;
+ int vendor_id, chip_id, i, j;
+
+ if (!dri3_get_pci_id_from_fd(fd, &vendor_id, &chip_id))
+ return NULL;
for (i = 0; driver_map[i].driver; i++) {
if (vendor_id != driver_map[i].vendor_id)
@@ -139,8 +220,5 @@ dri3_get_driver_for_fd(int fd)
}
out:
- udev_device_unref(device);
- udev_unref(udev);
-
return driver;
}
--
1.8.4.2
[PATCH] Don't use libudev for glx/dri3
libudev doesn't have a stable API/ABI, and if the application wants to use one
version, we'd best not load another into libGL.
Signed-off-by: Keith Packard
---
Sorry for the patch spam; I hadn't rebased in a while and there was a
configure.ac conflict. Here's a version which should apply cleanly to master.
configure.ac | 8
src/glx/dri3_common.c | 104 +++---
2 files changed, 90 insertions(+), 22 deletions(-)
diff --git a/configure.ac b/configure.ac
index fb16338..656d9d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -821,9 +821,6 @@ xyesno)
PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
if test x"$enable_dri3" = xyes; then
-if test x"$have_libudev" != xyes; then
- AC_MSG_ERROR([DRI3 requires libudev >= $LIBUDEV_REQUIRED])
-fi
PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >=
$PRESENTPROTO_REQUIRED])
fi
@@ -847,11 +844,6 @@ xyesno)
X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
GL_LIB_DEPS="$DRIGL_LIBS"
-if test x"$enable_dri3$have_libudev" = xyesyes; then
-X11_INCLUDES="$X11_INCLUDES $LIBUDEV_CFLAGS"
-GL_LIB_DEPS="$GL_LIB_DEPS $LIBUDEV_LIBS"
-fi
-
# need DRM libs, $PTHREAD_LIBS, etc.
GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
GL_PC_LIB_PRIV="-lm $PTHREAD_LIBS $DLOPEN_LIBS"
diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
index c758f96..7330d79 100644
--- a/src/glx/dri3_common.c
+++ b/src/glx/dri3_common.c
@@ -72,22 +72,41 @@
#include "dri3_priv.h"
#define DRIVER_MAP_DRI3_ONLY
+
#include "pci_ids/pci_id_driver_map.h"
+static dev_t
+dri3_rdev_from_fd(int fd)
+{
+ struct stat buf;
+
+ if (fstat(fd, &buf) < 0) {
+ ErrorMessageF("DRI3: failed to stat fd %d", fd);
+ return 0;
+ }
+ return buf.st_rdev;
+}
+
+/*
+ * There are multiple udev library versions, and they aren't polite about
+ * symbols, so just avoid using it until some glorious future when the udev
+ * developers figure out how to not break things
+ */
+
+#define USE_UDEV 0
+#if USE_UDEV
#include
static struct udev_device *
dri3_udev_device_new_from_fd(struct udev *udev, int fd)
{
struct udev_device *device;
- struct stat buf;
+ dev_t rdev = dri3_rdev_from_fd(fd);
- if (fstat(fd, &buf) < 0) {
- ErrorMessageF("DRI3: failed to stat fd %d", fd);
+ if (rdev == 0)
return NULL;
- }
- device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
+ device = udev_device_new_from_devnum(udev, 'c', rdev);
if (device == NULL) {
ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
return NULL;
@@ -96,19 +115,20 @@ dri3_udev_device_new_from_fd(struct udev *udev, int fd)
return device;
}
-char *
-dri3_get_driver_for_fd(int fd)
+static int
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
{
struct udev *udev;
struct udev_device *device, *parent;
const char *pci_id;
- char *driver = NULL;
- int vendor_id, chip_id, i, j;
+ int ret = 0;
udev = udev_new();
+ if (!udev)
+ goto no_udev;
device = dri3_udev_device_new_from_fd(udev, fd);
if (device == NULL)
- return NULL;
+ goto no_dev;
parent = udev_device_get_parent(device);
if (parent == NULL) {
@@ -118,10 +138,69 @@ dri3_get_driver_for_fd(int fd)
pci_id = udev_device_get_property_value(parent, "PCI_ID");
if (pci_id == NULL ||
- sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
+ sscanf(pci_id, "%x:%x", vendorp, chipp) != 2) {
ErrorMessageF("DRI3: malformed or no PCI ID");
goto out;
}
+ ret = 1;
+
+out:
+ udev_device_unref(device);
+no_dev:
+ udev_unref(udev);
+no_udev:
+ return ret;
+}
+#else
+
+#define SYS_PATH_MAX256
+
+static int
+dri3_read_hex(dev_t rdev, char *entry, int *value)
+{
+ char path[SYS_PATH_MAX];
+ FILE *f;
+ int r;
+
+ snprintf(path, sizeof (path), "/sys/dev/char/%u:%u/device/%s",
+major(rdev), minor(rdev), entry);
+
+ f = fopen(path,"r");
+ if (f == NULL)
+ return 0;
+
+ r = fscanf(f, "0x%x\n", value);
+ fclose(f);
+ if (r != 1)
+ return 0;
+ return 1;
+}
+
+static int
+dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
+{
+ dev_trdev = dri3_rdev_from_fd(fd);
+
+ if (!rdev)
+ return 0;
+
+ if (!dri3_read_hex(rdev, "vendor", vendorp))
+ return 0;
+ if (!dri3_read_hex(rdev, "device", chipp))
+ return 0;
+ return 1;
+}
+
+#endif
+
+char *
+dri3_get_driver_for_fd(int fd)
+{
+ char *driver = NULL;
+ int vendor_id, chip_id, i, j;
+
+ if (!dri3_get_pci_id_from_fd(fd, &vendor_id, &chip_id))
+ return NULL;
for (i = 0; driver_map[i].driver; i++) {
if (vendor_id != driver_m
[Mesa-dev] [PATCH] Don't use libudev for glx/dri3
Emil Velikov writes: > On 18/11/13 01:08, Keith Packard wrote: >> libudev doesn't have a stable API/ABI, and if the application wants to use >> one >> version, we'd best not load another into libGL. >> >> Signed-off-by: Keith Packard >> --- >> > Hi Keith, > > Firstly, I would like to apologise for the rather daft questions. > > With that said, looking through your patch I've noticed that (most of) > your int functions are returning 0 or failure and 1 on success. Were > those functions meant to return boolean/bool? Sure, but I was too lazy to figure out which kind of bool belongs in that part of mesa... -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/83478e60/attachment.pgp>
[Mesa-dev] [PATCH] Don't use libudev for glx/dri3
On 11/17/2013 06:43 PM, Keith Packard wrote: > Emil Velikov writes: > >> On 18/11/13 01:08, Keith Packard wrote: >>> libudev doesn't have a stable API/ABI, and if the application wants to use >>> one >>> version, we'd best not load another into libGL. >>> >>> Signed-off-by: Keith Packard >>> --- >>> >> Hi Keith, >> >> Firstly, I would like to apologise for the rather daft questions. >> >> With that said, looking through your patch I've noticed that (most of) >> your int functions are returning 0 or failure and 1 on success. Were >> those functions meant to return boolean/bool? > > Sure, but I was too lazy to figure out which kind of bool belongs in > that part of mesa... For non-API facing stuff, you can just use stdbool.h's bool/true/false. --Ken
[Mesa-dev] [PATCH] Don't use libudev for glx/dri3
Kenneth Graunke writes: > For non-API facing stuff, you can just use stdbool.h's > bool/true/false. tnx. I pushed that to my dri3 branch. Btw, that branch also has some gallium support for __DRIimageDriverExtension. I don't have any hardware to test with, so it's surely broken in some major ways, but it might show where the hooks need to be. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131117/a8c1f829/attachment.pgp>
[PATCH] drm/ttm: Don't move non-existing data
If ttm_bo_move_memcpy was instructed to move a non-populated ttm to
io memory, it would first populate the ttm, then move the data and then
destroy the ttm. That's stupid. However, some drivers might have relied on
this to clear io memory from old stuff. So instead of a NOP, which would
be the most efficient, just clear the destination.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo_util.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 4834c46..15b86a9 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -350,10 +350,13 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
goto out2;
/*
-* Move nonexistent data. NOP.
+* Don't move nonexistent data. Clear destination instead.
*/
- if (old_iomap == NULL && ttm == NULL)
+ if (old_iomap == NULL &&
+ (ttm == NULL || ttm->state == tt_unpopulated)) {
+ memset_io(new_iomap, 0, new_mem->num_pages*PAGE_SIZE);
goto out2;
+ }
/*
* TTM might be null for moves within the same region.
--
1.7.10.4
