[PATCH libdrm 1/2] configure: Stop using AM_MAINTAINER_MODE
On Tue, Mar 10, 2015 at 16:33:17 +, Emil Velikov wrote: > Hi Julien, > On 9 March 2015 at 20:28, Julien Cristau wrote: > > On Mon, Mar 9, 2015 at 12:08:16 +, Emil Velikov wrote: > > > >> By using it, any modifications to configure.ac or the Makefile.am files > >> won't trigger a rebuild of the makefiles. Drop the switch from the > >> autogen.sh as well. > >> > > Since it was set to enabled in configure.ac, the above is not true, > > unless you explicitly pass --disable-maintainer-mode to configure. > > > Hmm... you're absolutely correct here. The following commit message > should be more appropriate. > > AM_MAINTAINER_MODE can be used to disable generation of rebuild rules. > This is not something we want to condone/support, considering it can > cause greater problems than the perceived benefits. Additionally the > Automake manual leans towards avoiding the use of AM_MAINTAINER_MODE. > > http://www.gnu.org/software/automake/manual/html_node/maintainer_002dmode.html > > > That is unless you're in favour of keeping it ? Afaics at least some X > components tend to avoid it. > I don't really care whether it stays or goes, but your new commit message looks good to me :) Cheers, Julien
[PATCH libdrm 1/2] configure: Stop using AM_MAINTAINER_MODE
On Mon, Mar 9, 2015 at 12:08:16 +, Emil Velikov wrote: > By using it, any modifications to configure.ac or the Makefile.am files > won't trigger a rebuild of the makefiles. Drop the switch from the > autogen.sh as well. > Since it was set to enabled in configure.ac, the above is not true, unless you explicitly pass --disable-maintainer-mode to configure. Cheers, Julien
[PATCH] drm/vmwgfx: Fix drm.h include
On Tue, Sep 16, 2014 at 09:43:50 -0400, Josh Boyer wrote: > On Fri, Sep 5, 2014 at 1:19 PM, Josh Boyer > wrote: > > The userspace drm.h include doesn't prefix the drm directory. This can lead > > to compile failures as /usr/include/drm/ isn't in the standard gcc include > > paths. Fix it to be , which matches the rest of the driver drm > > header files that get installed into /usr/include/drm. > > > > Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138759 > > > > Fixes: 1d7a5cbf8f74e > > Reported-by: Jeffrey Bastian > > Signed-off-by: Josh Boyer > > Ping? Did this get queued anywhere? > Any reason this doesn't just #include "drm.h"? That should work whether the drm headers are installed in /usr/include/drm/ or /usr/include/libdrm/... Cheers, Julien, who doesn't have a /usr/include/drm/ either
Re: 3.11-rc7: i915: stuck on render ring
On Thu, Oct 3, 2013 at 22:42:06 +0200, Pavel Machek wrote: On Wed 2013-09-04 11:08:14, Chris Wilson wrote: On Tue, Sep 03, 2013 at 09:06:47PM +0200, Pavel Machek wrote: Hi! I was happily using X... and then screen froze. Mouse still moves. Switching to text console still worked, good. It is first time in a while, normally this machine works well. i915_error_state is attached. Any ideas? It's a bug in the ddx, that was fixed in 2.14.902 (2011-03-29). Aha, so I need to update X or rather debian should update the X server. Thanks for the info. Pavel I don't know what version you're running, but stable has 2.19, and unstable has 2.21.15. Both are 2.14.902. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Mon, Oct 1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote: > - without this patch, modern X errors out instead of starting, >because the intel driver requires kms. (In a hypothetical better >world, userspace would know to fall back to vesa or something.) > I'd expect X to start with vesa or fbdev, rather than erroring out? Cheers, Julien
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Mon, Oct 1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote: - without this patch, modern X errors out instead of starting, because the intel driver requires kms. (In a hypothetical better world, userspace would know to fall back to vesa or something.) I'd expect X to start with vesa or fbdev, rather than erroring out? Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
On Tue, Jun 12, 2012 at 20:04:03 -0700, Ian Romanick wrote: > Isn't CLOCK_MONOTONIC per-process? "This clock represents the monotonic clock for the system." (http://pubs.opengroup.org/onlinepubs/009604599/functions/clock_getres.html) So, no. Cheers, Julien
Re: RFC: Change OML_sync_control UST to CLOCK_MONOTONIC
On Tue, Jun 12, 2012 at 20:04:03 -0700, Ian Romanick wrote: Isn't CLOCK_MONOTONIC per-process? This clock represents the monotonic clock for the system. (http://pubs.opengroup.org/onlinepubs/009604599/functions/clock_getres.html) So, no. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Only build test programs with make check
On Sat, Mar 17, 2012 at 14:40:04 -0400, Matt Turner wrote: > On Sat, Mar 17, 2012 at 2:35 PM, Jakob Bornecrantz > wrote: > > With my limited knowledge of automake I'm going to have > > to NACK this patch. Most of these programs are used during > > driver bring up to test things out, often we also modify > > them a bit to suit our need. > > > > If this patch doesn't make this any harder then > > disregard my NACK. > > Harder, like having to run make check? > > I'm not sure about modeprint, so I can drop that, but the rest look > like programs you'd want to run during make check. I don't think you want to run any of them during make check, they test the running kernel AFAIK which isn't all that relevant. Cheers, Julien
Re: [PATCH] Only build test programs with make check
On Sat, Mar 17, 2012 at 14:40:04 -0400, Matt Turner wrote: On Sat, Mar 17, 2012 at 2:35 PM, Jakob Bornecrantz ja...@vmware.com wrote: With my limited knowledge of automake I'm going to have to NACK this patch. Most of these programs are used during driver bring up to test things out, often we also modify them a bit to suit our need. If this patch doesn't make this any harder then disregard my NACK. Harder, like having to run make check? I'm not sure about modeprint, so I can drop that, but the rest look like programs you'd want to run during make check. I don't think you want to run any of them during make check, they test the running kernel AFAIK which isn't all that relevant. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Don't build Intel DRM if $CHOST is not i?86-* or x86_64-*
On Wed, Feb 1, 2012 at 13:01:58 -0800, Jeremy Huddleston wrote: > yeah, that's probably cleaner (I guess it'll avoid the -*), but it should > have the same effect. > I get host_os=linux-gnu here afaict, so not really the same effect, no. Cheers, Julien
[PATCH] Don't build Intel DRM if $CHOST is not i?86-* or x86_64-*
On Mon, Jan 30, 2012 at 15:25:20 -0800, Jeremy Huddleston wrote: > This fixes a failure in 'make check' found by the tinderbox when trying to > build this code on Linux/ppc. This code is only designed to run on > Intel platforms, so don't even bother building it if we're not in that set. > > Found-by: Tinderbox > Signed-off-by: Jeremy Huddleston > --- > > It now causes the intel bits to not build on my Linux/ppc tinderbox, but I'd > appreciate someone verifying that it does the right thing on intel boxes as > well. > > configure.ac |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 773167f..f5ebc1d 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -250,7 +250,10 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno"; then > > else > if test "x$INTEL" != "xno"; then > - INTEL=yes > + case $host_os in > + i?86-*|x86_64-*) INTEL=yes ;; > + *) INTEL=no ;; > + esac > fi don't you want to check host_cpu rather than host_os? Cheers, Julien
Re: [PATCH] Don't build Intel DRM if $CHOST is not i?86-* or x86_64-*
On Mon, Jan 30, 2012 at 15:25:20 -0800, Jeremy Huddleston wrote: This fixes a failure in 'make check' found by the tinderbox when trying to build this code on Linux/ppc. This code is only designed to run on Intel platforms, so don't even bother building it if we're not in that set. Found-by: Tinderbox Signed-off-by: Jeremy Huddleston jerem...@apple.com --- It now causes the intel bits to not build on my Linux/ppc tinderbox, but I'd appreciate someone verifying that it does the right thing on intel boxes as well. configure.ac |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 773167f..f5ebc1d 100644 --- a/configure.ac +++ b/configure.ac @@ -250,7 +250,10 @@ if test x$INTEL != xno -o x$RADEON != xno; then else if test x$INTEL != xno; then - INTEL=yes + case $host_os in + i?86-*|x86_64-*) INTEL=yes ;; + *) INTEL=no ;; + esac fi don't you want to check host_cpu rather than host_os? Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Don't build Intel DRM if $CHOST is not i?86-* or x86_64-*
On Wed, Feb 1, 2012 at 13:01:58 -0800, Jeremy Huddleston wrote: yeah, that's probably cleaner (I guess it'll avoid the -*), but it should have the same effect. I get host_os=linux-gnu here afaict, so not really the same effect, no. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Wed, Jul 27, 2011 at 15:08:08 +, Ben Widawsky wrote: > On Thu, Jul 21, 2011 at 11:22:12PM +0200, Julien Cristau wrote: > > On Thu, Jul 21, 2011 at 13:54:41 +, Ben Widawsky wrote: > > > > > On Tue, Jul 19, 2011 at 11:06:17PM +0200, Julien Cristau wrote: > > > > On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: > > > > > > > > > +#define SHADER_DEBUG_SOCKET "/tmp/gen_debug" > > > > > > > > Not sure what this is used for, but does it really need to be in /tmp? > > > > > > It is the shared socket between a debug client (ie. Mesa) and the > > > debugger. I don't care where it goes, do you have any recommendations? > > > > > Somewhere under $HOME is probably better than a predictable file name in > > /tmp. > > $HOME is not great because it requires a little hackery to accomplish. > The debugger will be running as root, and so if we put it in root's > $HOME, mesa may not be able to reach it. > Ah, I didn't realise this would run as root. Would /run (or /var/run) be ok then? Alternately, use an abstract domain socket to not have to care about the underlying filesystem. Cheers, Julien
Re: [Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Wed, Jul 27, 2011 at 15:08:08 +, Ben Widawsky wrote: On Thu, Jul 21, 2011 at 11:22:12PM +0200, Julien Cristau wrote: On Thu, Jul 21, 2011 at 13:54:41 +, Ben Widawsky wrote: On Tue, Jul 19, 2011 at 11:06:17PM +0200, Julien Cristau wrote: On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: +#define SHADER_DEBUG_SOCKET /tmp/gen_debug Not sure what this is used for, but does it really need to be in /tmp? It is the shared socket between a debug client (ie. Mesa) and the debugger. I don't care where it goes, do you have any recommendations? Somewhere under $HOME is probably better than a predictable file name in /tmp. $HOME is not great because it requires a little hackery to accomplish. The debugger will be running as root, and so if we put it in root's $HOME, mesa may not be able to reach it. Ah, I didn't realise this would run as root. Would /run (or /var/run) be ok then? Alternately, use an abstract domain socket to not have to care about the underlying filesystem. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Thu, Jul 21, 2011 at 13:54:41 +, Ben Widawsky wrote: > On Tue, Jul 19, 2011 at 11:06:17PM +0200, Julien Cristau wrote: > > On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: > > > > > +#define SHADER_DEBUG_SOCKET "/tmp/gen_debug" > > > > Not sure what this is used for, but does it really need to be in /tmp? > > It is the shared socket between a debug client (ie. Mesa) and the > debugger. I don't care where it goes, do you have any recommendations? > Somewhere under $HOME is probably better than a predictable file name in /tmp. Cheers, Julien
Re: [Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Thu, Jul 21, 2011 at 13:54:41 +, Ben Widawsky wrote: On Tue, Jul 19, 2011 at 11:06:17PM +0200, Julien Cristau wrote: On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: +#define SHADER_DEBUG_SOCKET /tmp/gen_debug Not sure what this is used for, but does it really need to be in /tmp? It is the shared socket between a debug client (ie. Mesa) and the debugger. I don't care where it goes, do you have any recommendations? Somewhere under $HOME is probably better than a predictable file name in /tmp. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: > +#define SHADER_DEBUG_SOCKET "/tmp/gen_debug" Not sure what this is used for, but does it really need to be in /tmp? Cheers, Julien
Re: [Intel-gfx] [PATCH 01/10] intel: shared header for shader debugging
On Wed, Jul 13, 2011 at 13:51:43 -0700, Ben Widawsky wrote: +#define SHADER_DEBUG_SOCKET /tmp/gen_debug Not sure what this is used for, but does it really need to be in /tmp? Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRI2/GLX: fix swap event handling
On Thu, Apr 28, 2011 at 13:27:22 -0700, Jesse Barnes wrote:
> diff --git a/glx/glxdri2.c b/glx/glxdri2.c
> index d979717..654b4ae 100644
> --- a/glx/glxdri2.c
> +++ b/glx/glxdri2.c
> @@ -192,8 +192,17 @@ __glXdriSwapEvent(ClientPtr client, void *data, int
> type, CARD64 ust,
> wire.ust_lo = ust & 0x;
> wire.msc_hi = msc >> 32;
> wire.msc_lo = msc & 0x;
> -wire.sbc_hi = sbc >> 32;
> -wire.sbc_lo = sbc & 0x;
> +wire.sbc_hi = 0;
> +
> +if (DRI2ClientSupportsSBC(client)) {
> + wire.sbc_lo0 = sbc & 0xff;
> + wire.sbc_lo8 = (sbc >> 8) & 0xff;
> + wire.sbc_lo16 = (sbc >> 16) & 0xff;
This one should be wire.sbc_lo16 = (sbc >> 16) & 0x;
> +} else {
> + wire.sbc_lo0 = 0;
> + wire.sbc_lo8 = 0;
> + wire.sbc_lo16 = 0;
> +}
>
> WriteEventsToClient(client, 1, (xEvent *) );
> }
Also I think big endian clients (when built against the old protocol
header) will expect the low byte of event_type where you now have
sbc_lo8, so you would need to swap them. Same for the dri2 event.
[...]
> diff --git a/include/protocol-versions.h b/include/protocol-versions.h
> index 8692ded..8fde917 100644
> --- a/include/protocol-versions.h
> +++ b/include/protocol-versions.h
> @@ -57,7 +57,7 @@
>
> /* GLX */
> #define SERVER_GLX_MAJOR_VERSION 1
> -#define SERVER_GLX_MINOR_VERSION 4
> +#define SERVER_GLX_MINOR_VERSION 5
>
Do we get to bump the GLX protocol version? Somehow I thought that was
khronos business.
> /* Xinerama */
> #define SERVER_PANORAMIX_MAJOR_VERSION 1
Cheers,
Julien
Re: [PATCH] DRI2/GLX: fix swap event handling
On Thu, Apr 28, 2011 at 13:27:22 -0700, Jesse Barnes wrote:
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index d979717..654b4ae 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -192,8 +192,17 @@ __glXdriSwapEvent(ClientPtr client, void *data, int
type, CARD64 ust,
wire.ust_lo = ust 0x;
wire.msc_hi = msc 32;
wire.msc_lo = msc 0x;
-wire.sbc_hi = sbc 32;
-wire.sbc_lo = sbc 0x;
+wire.sbc_hi = 0;
+
+if (DRI2ClientSupportsSBC(client)) {
+ wire.sbc_lo0 = sbc 0xff;
+ wire.sbc_lo8 = (sbc 8) 0xff;
+ wire.sbc_lo16 = (sbc 16) 0xff;
This one should be wire.sbc_lo16 = (sbc 16) 0x;
+} else {
+ wire.sbc_lo0 = 0;
+ wire.sbc_lo8 = 0;
+ wire.sbc_lo16 = 0;
+}
WriteEventsToClient(client, 1, (xEvent *) wire);
}
Also I think big endian clients (when built against the old protocol
header) will expect the low byte of event_type where you now have
sbc_lo8, so you would need to swap them. Same for the dri2 event.
[...]
diff --git a/include/protocol-versions.h b/include/protocol-versions.h
index 8692ded..8fde917 100644
--- a/include/protocol-versions.h
+++ b/include/protocol-versions.h
@@ -57,7 +57,7 @@
/* GLX */
#define SERVER_GLX_MAJOR_VERSION 1
-#define SERVER_GLX_MINOR_VERSION 4
+#define SERVER_GLX_MINOR_VERSION 5
Do we get to bump the GLX protocol version? Somehow I thought that was
khronos business.
/* Xinerama */
#define SERVER_PANORAMIX_MAJOR_VERSION 1
Cheers,
Julien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Pretty print out the reason for rejecting the mode
On Tue, Apr 5, 2011 at 21:50:15 +0100, Chris Wilson wrote: > + if ((unsigned)status > ARRAY_SIZE(strings)) off by one? > + return "unknown"; > + > + return strings[status]; > +} > + Cheers, Julien
Re: [PATCH] drm: Pretty print out the reason for rejecting the mode
On Tue, Apr 5, 2011 at 21:50:15 +0100, Chris Wilson wrote: + if ((unsigned)status ARRAY_SIZE(strings)) off by one? + return unknown; + + return strings[status]; +} + Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status
On Tue, Mar 15, 2011 at 11:40:00 +, Chris Wilson wrote: > [Digression: what is upowerd doing reading those power hungry files?] > Apparently, checking "docked" status every 30 seconds, by reading the status of drm outputs. Where "docked" means "more than one output connected". Yes, it's silly. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613745 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618329 Cheers, Julien
Re: [Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status
On Tue, Mar 15, 2011 at 11:40:00 +, Chris Wilson wrote: [Digression: what is upowerd doing reading those power hungry files?] Apparently, checking docked status every 30 seconds, by reading the status of drm outputs. Where docked means more than one output connected. Yes, it's silly. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613745 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618329 Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
OpenArena Anholt Demo
On Thu, Feb 10, 2011 at 17:02:02 +0100, Sven Arvidsson wrote: > On Thu, 2011-02-10 at 16:54 +0100, Sedat Dilek wrote: > > [ SOLVED ] > > > > Remove dot-openarena directory, copy files/dirs to (new?) ~/openarena/ dir. > > > > $ rm -rf ~/.openarena && cp -av anholt.cfg demos ~/openarena/baseoa/ > > This sounds very much like a bug in the Debian package, could you report > it? > http://bugs.debian.org/612782 Cheers, Julien
Re: OpenArena Anholt Demo
On Thu, Feb 10, 2011 at 17:02:02 +0100, Sven Arvidsson wrote: On Thu, 2011-02-10 at 16:54 +0100, Sedat Dilek wrote: [ SOLVED ] Remove dot-openarena directory, copy files/dirs to (new?) ~/openarena/ dir. $ rm -rf ~/.openarena cp -av anholt.cfg demos ~/openarena/baseoa/ This sounds very much like a bug in the Debian package, could you report it? http://bugs.debian.org/612782 Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: fix headers to include linux/types.h
On Wed, Dec 1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote: > For headers that get exported to userland and make use of u32 style > type names, it is advised to include linux/types.h. > > This fixes 5 headers_check warnings. > How many times does this need to be NAKed? These headers are shared with the BSDs, and they include drm.h which has the linux/types.h include on linux already. Cheers, Julien
Re: [PATCH 1/4] drm: fix headers to include linux/types.h
On Wed, Dec 1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote: For headers that get exported to userland and make use of u32 style type names, it is advised to include linux/types.h. This fixes 5 headers_check warnings. How many times does this need to be NAKed? These headers are shared with the BSDs, and they include drm.h which has the linux/types.h include on linux already. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: Fix two race conditions
On Thu, Sep 30, 2010 at 12:36:45 +0200, Thomas Hellstrom wrote: > This fixes a race pointed out by Dave Airlie where we don't take a buffer > object about to be destroyed off the LRU lists properly. It also fixes a rare > case where a buffer object could be destroyed in the middle of an > accelerated eviction. > > The patch also adds a utility function that can be used to prematurely > release GPU memory space usage of an object waiting to be destroyed. > For example during eviction or swapout. > > Signed-off-by: Thomas Hellstrom FWIW, from the debian bug: Tested-by: "Eduardo I." Cheers, Julien
Re: [PATCH] drm/ttm: Fix two race conditions
On Thu, Sep 30, 2010 at 12:36:45 +0200, Thomas Hellstrom wrote: This fixes a race pointed out by Dave Airlie where we don't take a buffer object about to be destroyed off the LRU lists properly. It also fixes a rare case where a buffer object could be destroyed in the middle of an accelerated eviction. The patch also adds a utility function that can be used to prematurely release GPU memory space usage of an object waiting to be destroyed. For example during eviction or swapout. Signed-off-by: Thomas Hellstrom thellst...@vmware.com FWIW, from the debian bug: Tested-by: Eduardo I. persegui...@gmail.com Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] Add _DRM_HIDDEN macro
On Sat, Jun 12, 2010 at 16:49:09 +0200, Tilman Sauerbeck wrote: > > +# define _X_HIDDEN > ^ > This should say _DRM_HIDDEN, I guess :) > Sigh, yes, thanks. Cheers, Julien
[PATCH 1/3] Add _DRM_HIDDEN macro
On Thu, Jun 10, 2010 at 23:50:09 +0200, Julien Cristau wrote: > Introduce a new internal header since that doesn't seem to exist yet. > Or maybe I should rename xf86atomic.h instead. > --- > xf86drm-internals.h | 12 > 1 files changed, 12 insertions(+), 0 deletions(-) > create mode 100644 xf86drm-internals.h > Sorry, forgot to include it in Makefile.am. If the rest of the series is acked I can resend with the fix. Cheers, Julien
[PATCH 3/3] radeon: don't export internal functions
Also drop prototypes for nonexistent functions.
---
radeon/bof.h | 41 +++--
1 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/radeon/bof.h b/radeon/bof.h
index 014affb..239c98a 100644
--- a/radeon/bof.h
+++ b/radeon/bof.h
@@ -28,6 +28,7 @@
#include
#include
+#include "xf86drm-internals.h"
#define BOF_TYPE_STRING0
#define BOF_TYPE_NULL 1
@@ -51,34 +52,30 @@ typedef struct bof {
longoffset;
} bof_t;
-extern int bof_file_flush(bof_t *root);
-extern bof_t *bof_file_new(const char *filename);
-extern int bof_object_dump(bof_t *object, const char *filename);
-
/* object */
-extern bof_t *bof_object(void);
-extern bof_t *bof_object_get(bof_t *object, const char *keyname);
-extern int bof_object_set(bof_t *object, const char *keyname, bof_t *value);
+extern _DRM_HIDDEN bof_t *bof_object(void);
+extern _DRM_HIDDEN bof_t *bof_object_get(bof_t *object, const char *keyname);
+extern _DRM_HIDDEN int bof_object_set(bof_t *object, const char *keyname,
bof_t *value);
/* array */
-extern bof_t *bof_array(void);
-extern int bof_array_append(bof_t *array, bof_t *value);
-extern bof_t *bof_array_get(bof_t *bof, unsigned i);
-extern unsigned bof_array_size(bof_t *bof);
+extern _DRM_HIDDEN bof_t *bof_array(void);
+extern _DRM_HIDDEN int bof_array_append(bof_t *array, bof_t *value);
+extern _DRM_HIDDEN bof_t *bof_array_get(bof_t *bof, unsigned i);
+extern _DRM_HIDDEN unsigned bof_array_size(bof_t *bof);
/* blob */
-extern bof_t *bof_blob(unsigned size, void *value);
-extern unsigned bof_blob_size(bof_t *bof);
-extern void *bof_blob_value(bof_t *bof);
+extern _DRM_HIDDEN bof_t *bof_blob(unsigned size, void *value);
+extern _DRM_HIDDEN unsigned bof_blob_size(bof_t *bof);
+extern _DRM_HIDDEN void *bof_blob_value(bof_t *bof);
/* string */
-extern bof_t *bof_string(const char *value);
+extern _DRM_HIDDEN bof_t *bof_string(const char *value);
/* int32 */
-extern bof_t *bof_int32(int32_t value);
-extern int32_t bof_int32_value(bof_t *bof);
+extern _DRM_HIDDEN bof_t *bof_int32(int32_t value);
+extern _DRM_HIDDEN int32_t bof_int32_value(bof_t *bof);
/* common functions */
-extern void bof_decref(bof_t *bof);
-extern void bof_incref(bof_t *bof);
-extern bof_t *bof_load_file(const char *filename);
-extern int bof_dump_file(bof_t *bof, const char *filename);
-extern void bof_print(bof_t *bof);
+extern _DRM_HIDDEN void bof_decref(bof_t *bof);
+extern _DRM_HIDDEN void bof_incref(bof_t *bof);
+extern _DRM_HIDDEN bof_t *bof_load_file(const char *filename);
+extern _DRM_HIDDEN int bof_dump_file(bof_t *bof, const char *filename);
+extern _DRM_HIDDEN void bof_print(bof_t *bof);
static inline int bof_is_object(bof_t *bof){return (bof->type ==
BOF_TYPE_OBJECT);}
static inline int bof_is_blob(bof_t *bof){return (bof->type == BOF_TYPE_BLOB);}
--
1.7.1
[PATCH 2/3] libkms: don't export internal functions
---
libkms/internal.h |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/libkms/internal.h b/libkms/internal.h
index 63122d1..efb781a 100644
--- a/libkms/internal.h
+++ b/libkms/internal.h
@@ -30,6 +30,7 @@
#define INTERNAL_H_
#include "libkms.h"
+#include "xf86drm-internals.h"
struct kms_driver
{
@@ -62,12 +63,12 @@ struct kms_bo
unsigned handle;
};
-int linux_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int linux_create(int fd, struct kms_driver **out);
-int vmwgfx_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int vmwgfx_create(int fd, struct kms_driver **out);
-int intel_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int intel_create(int fd, struct kms_driver **out);
-int nouveau_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int nouveau_create(int fd, struct kms_driver **out);
#endif
--
1.7.1
[PATCH 1/3] Add _DRM_HIDDEN macro
Introduce a new internal header since that doesn't seem to exist yet.
Or maybe I should rename xf86atomic.h instead.
---
xf86drm-internals.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
create mode 100644 xf86drm-internals.h
diff --git a/xf86drm-internals.h b/xf86drm-internals.h
new file mode 100644
index 000..bf5ff51
--- /dev/null
+++ b/xf86drm-internals.h
@@ -0,0 +1,12 @@
+#ifndef XF86DRM_INTERNALS_H
+#define XF86DRM_INTERNALS_H
+
+#if defined(__GNUC__) && (__GNUC__ >= 4)
+# define _DRM_HIDDEN __attribute__((visibility("hidden")))
+#elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550)
+# define _DRM_HIDDEN __hidden
+#else /* not gcc >= 4 and not Sun Studio >= 8 */
+# define _X_HIDDEN
+#endif /* GNUC >= 4 */
+
+#endif
--
1.7.1
[PATCH 2/3] libkms: don't export internal functions
---
libkms/internal.h |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/libkms/internal.h b/libkms/internal.h
index 63122d1..efb781a 100644
--- a/libkms/internal.h
+++ b/libkms/internal.h
@@ -30,6 +30,7 @@
#define INTERNAL_H_
#include libkms.h
+#include xf86drm-internals.h
struct kms_driver
{
@@ -62,12 +63,12 @@ struct kms_bo
unsigned handle;
};
-int linux_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int linux_create(int fd, struct kms_driver **out);
-int vmwgfx_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int vmwgfx_create(int fd, struct kms_driver **out);
-int intel_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int intel_create(int fd, struct kms_driver **out);
-int nouveau_create(int fd, struct kms_driver **out);
+_DRM_HIDDEN int nouveau_create(int fd, struct kms_driver **out);
#endif
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] Add _DRM_HIDDEN macro
On Thu, Jun 10, 2010 at 23:50:09 +0200, Julien Cristau wrote: Introduce a new internal header since that doesn't seem to exist yet. Or maybe I should rename xf86atomic.h instead. --- xf86drm-internals.h | 12 1 files changed, 12 insertions(+), 0 deletions(-) create mode 100644 xf86drm-internals.h Sorry, forgot to include it in Makefile.am. If the rest of the series is acked I can resend with the fix. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] Add _DRM_HIDDEN macro
Introduce a new internal header since that doesn't seem to exist yet. Or maybe I should rename xf86atomic.h instead. --- xf86drm-internals.h | 12 1 files changed, 12 insertions(+), 0 deletions(-) create mode 100644 xf86drm-internals.h diff --git a/xf86drm-internals.h b/xf86drm-internals.h new file mode 100644 index 000..bf5ff51 --- /dev/null +++ b/xf86drm-internals.h @@ -0,0 +1,12 @@ +#ifndef XF86DRM_INTERNALS_H +#define XF86DRM_INTERNALS_H + +#if defined(__GNUC__) (__GNUC__ = 4) +# define _DRM_HIDDEN __attribute__((visibility(hidden))) +#elif defined(__SUNPRO_C) (__SUNPRO_C = 0x550) +# define _DRM_HIDDEN __hidden +#else /* not gcc = 4 and not Sun Studio = 8 */ +# define _X_HIDDEN +#endif /* GNUC = 4 */ + +#endif -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[alsa-devel] No mixers on ATI RS780 Azalia
On Mon, Jun 7, 2010 at 14:49:16 +0200, Jan Engelhardt wrote: > * The radeon.ko module does not have any PCI IDs defined, thus does not > get autoloaded like i915.ko. Is this intentional? It also seems > to default to modeset=0. It only defines PCI IDs (and gets autoloaded) if CONFIG_DRM_RADEON_KMS=y. Cheers, Julien
Re: [alsa-devel] No mixers on ATI RS780 Azalia
On Mon, Jun 7, 2010 at 14:49:16 +0200, Jan Engelhardt wrote: * The radeon.ko module does not have any PCI IDs defined, thus does not get autoloaded like i915.ko. Is this intentional? It also seems to default to modeset=0. It only defines PCI IDs (and gets autoloaded) if CONFIG_DRM_RADEON_KMS=y. Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add support for internal thermal sensors (v2)
On Tue, Jun 1, 2010 at 18:52:30 -0400, Alex Deucher wrote: > diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig > index 80c5b3e..2e3896d 100644 > --- a/drivers/gpu/drm/radeon/Kconfig > +++ b/drivers/gpu/drm/radeon/Kconfig > @@ -2,6 +2,7 @@ config DRM_RADEON_KMS > bool "Enable modesetting on radeon by default - NEW DRIVER" > depends on DRM_RADEON > depends on POWER_SUPPLY > + depends on HWMON > help > Choose this option if you want kernel modesetting enabled by default. > Shouldn't these be under CONFIG_DRM_RADEON, with _KMS only changing the default value of the modeset parameter? Otherwise you could still try to build the driver with _KMS off, and CONFIG_HWMON disabled (which I assume is going to fail). Cheers, Julien
[PATCH] MAINTAINERS, drm: dri-devel moved to freedesktop.org
Signed-off-by: Julien Cristau
---
The comment on top of drm_pciids.h seems obsolete, but that can be
cleaned up later...
MAINTAINERS |2 +-
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +-
include/drm/drm_pciids.h |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 449d444..fabd0a0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1950,7 +1950,7 @@ F:lib/kobj*
DRM DRIVERS
M: David Airlie
-L: dri-devel at lists.sourceforge.net
+L: dri-devel at lists.freedesktop.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
S: Maintained
F: drivers/gpu/drm/
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index ace630a..c1a79ba 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -26,7 +26,7 @@
#define __NOUVEAU_DRV_H__
#define DRIVER_AUTHOR "Stephane Marchesin"
-#define DRIVER_EMAIL "dri-devel at lists.sourceforge.net"
+#define DRIVER_EMAIL "dri-devel at lists.freedesktop.org"
#define DRIVER_NAME"nouveau"
#define DRIVER_DESC"nVidia Riva/TNT/GeForce"
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 04a6ebc..97bb761 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -1,6 +1,6 @@
/*
This file is auto-generated from the drm_pciids.txt in the DRM CVS
- Please contact dri-devel at lists.sf.net to add new cards to this list
+ Please contact dri-devel at lists.freedesktop.org to add new cards to this
list
*/
#define radeon_PCI_IDS \
{0x1002, 0x3150, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV380|RADEON_IS_MOBILITY}, \
--
1.7.0.4
[PATCH] MAINTAINERS, drm: dri-devel moved to freedesktop.org
Signed-off-by: Julien Cristau jcris...@debian.org
---
The comment on top of drm_pciids.h seems obsolete, but that can be
cleaned up later...
MAINTAINERS |2 +-
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +-
include/drm/drm_pciids.h |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 449d444..fabd0a0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1950,7 +1950,7 @@ F:lib/kobj*
DRM DRIVERS
M: David Airlie airl...@linux.ie
-L: dri-de...@lists.sourceforge.net
+L: dri-devel@lists.freedesktop.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
S: Maintained
F: drivers/gpu/drm/
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index ace630a..c1a79ba 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -26,7 +26,7 @@
#define __NOUVEAU_DRV_H__
#define DRIVER_AUTHOR Stephane Marchesin
-#define DRIVER_EMAIL dri-de...@lists.sourceforge.net
+#define DRIVER_EMAIL dri-devel@lists.freedesktop.org
#define DRIVER_NAMEnouveau
#define DRIVER_DESCnVidia Riva/TNT/GeForce
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 04a6ebc..97bb761 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -1,6 +1,6 @@
/*
This file is auto-generated from the drm_pciids.txt in the DRM CVS
- Please contact dri-de...@lists.sf.net to add new cards to this list
+ Please contact dri-devel@lists.freedesktop.org to add new cards to this list
*/
#define radeon_PCI_IDS \
{0x1002, 0x3150, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RV380|RADEON_IS_MOBILITY}, \
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
