Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path

2016-08-23 Thread Julien Cristau 
On Fri, Aug 19, 2016 at 09:04:14 -0700, Jason Ekstrand wrote:

> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
> index ad0148d..9fef960 100644
> --- a/src/intel/vulkan/Makefile.am
> +++ b/src/intel/vulkan/Makefile.am
> @@ -141,7 +141,7 @@ anv_timestamp.h:
>   $(AM_V_GEN) echo "#define ANV_TIMESTAMP \"$(TIMESTAMP_CMD)\"" > $@
>  
>  BUILT_SOURCES = $(VULKAN_GENERATED_FILES)
> -CLEANFILES = $(BUILT_SOURCES) dev_icd.json
> +CLEANFILES = $(BUILT_SOURCES) dev_icd.json intel_icd.json
>  EXTRA_DIST = \
>   $(top_srcdir)/include/vulkan/vk_icd.h \
>   anv_entrypoints_gen.py \
> @@ -170,6 +170,11 @@ dev_icd.json : dev_icd.json.in
>   -e "s#@build_libdir@#${abs_top_builddir}/${LIB_DIR}#" \
>   < $(srcdir)/dev_icd.json.in > $@
>  
> +intel_icd.json : intel_icd.json.in
> + $(AM_V_GEN) $(SED) \
> + -e "s#@install_libdir@#${libdir}#" \
> + < $(srcdir)/intel_icd.json.in > $@
> +
>  # Libvulkan with dummy gem. Used for unit tests.
>  libvulkan_test_la_SOURCES = $(VULKAN_GEM_STUB_FILES)
>  libvulkan_test_la_LIBADD = $(VULKAN_LIB_DEPS) -lX11-xcb

Incidentally, if intel_icd.json is generated then it should be removed
from EXTRA_DIST (but maybe intel_icd.json.in needs to be added?).

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path

2016-08-23 Thread Julien Cristau 
On Fri, Aug 19, 2016 at 09:04:14 -0700, Jason Ekstrand wrote:

> Not providing a path allows the ICD to work on multi-arch systems but
> breaks it if you install anywhere other than /usr/lib.  Given that users
> may be installing locally in .local or similar, we probably do want to
> provide a filename.  Distros can carry a revert of this commit if they want
> an intel_icd.json file without the path.
> 
If a user is going to install stuff in .local, don't they have
LD_LIBRARY_PATH pointing there too?

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv: Give the installed intel_icd.json file an absolute path

2016-08-22 Thread Julien Cristau 
On Mon, Aug 22, 2016 at 14:18:51 -0700, Jason Ekstrand wrote:

> On Mon, Aug 22, 2016 at 2:06 PM, Julien Cristau <jcris...@debian.org> wrote:
> 
> > On Fri, Aug 19, 2016 at 09:04:14 -0700, Jason Ekstrand wrote:
> >
> > > Not providing a path allows the ICD to work on multi-arch systems but
> > > breaks it if you install anywhere other than /usr/lib.  Given that users
> > > may be installing locally in .local or similar, we probably do want to
> > > provide a filename.  Distros can carry a revert of this commit if they
> > want
> > > an intel_icd.json file without the path.
> > >
> > If a user is going to install stuff in .local, don't they have
> > LD_LIBRARY_PATH pointing there too?
> >
> 
> Actually, no.  The loader will look for ICD files in
> .local/share/vulkan/icd.d and the ICD file will point to the right .so.  It
> should work out-of-the-box unless you either have a broken loader or we're
> installing something wrong.

So somehow they're only building the vulkan driver but not libGL or
anything else?  Still, I guess a bunch of people will need both a 32bit
and a 64bit version of the driver.  How is the 64-bit
~/.local/share/vulkan/icd.d/intel_icd.json not going to clash with the
32-bit ~/.local/share/vulkan/icd.d/intel_icd.json?  I'm just not seeing
how this solves the problem...

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Statically linking libstdc++ and libgcc

2015-03-20 Thread Julien Cristau 
On Thu, Mar 12, 2015 at 16:15:56 +0900, Michel Dänzer wrote:

 On 11.03.2015 05:07, Vivek Dasmohapatra wrote:
  Hi - As you probably already know, there can only be one version of
  libstdc++.so in your runtime link chain - This is usually not a problem,
  but when things are linked against the Steam runtime (for example), they
  can end up with two - one from the steam runtime, and one pulled in via
  the mesa dri libs from the OS/distribution.
 
 How can that happen? The problems I've seen related to this were usually
 because Steam overrides the system libstdc++ / libgcc with older
 versions, which breaks other system libraries.
 
 Can somebody please tell Valve that doing that is not okay? And it's not
 necessary either. Each library can be compared to the system version
 individually and only overridden when necessary, e.g. by putting each
 library into its own directory and only adding the necessary directories
 to $LD_LIBRARY_PATH. E.g. VMware use this approach in their products.
 
Yes please.  If libstdc++ or libgcc break ABI, that's something the
distributions will have to fix anyway, steam or no steam, so I don't see
how this helps anyone vs just making steam not override newer libs.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: Add a missing error check in _mesa_GetProgramBinary

2014-12-23 Thread Julien Cristau 
On Sun, Dec 21, 2014 at 12:08:44 -0800, Ian Romanick wrote:

 From: Ian Romanick ian.d.roman...@intel.com
 
 Signed-off-by: Ian Romanick ian.d.roman...@intel.com
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87516
 ---
  src/mesa/main/shaderapi.c | 26 --
  1 file changed, 20 insertions(+), 6 deletions(-)
 
 diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
 index 108e3f5..c7e2633 100644
 --- a/src/mesa/main/shaderapi.c
 +++ b/src/mesa/main/shaderapi.c
 @@ -1681,16 +1681,35 @@ _mesa_GetProgramBinary(GLuint program, GLsizei 
 bufSize, GLsizei *length,
 GLenum *binaryFormat, GLvoid *binary)
  {
 struct gl_shader_program *shProg;
 +   GLsizei length_dummy;
 GET_CURRENT_CONTEXT(ctx);
  
 shProg = _mesa_lookup_shader_program_err(ctx, program, 
 glGetProgramBinary);
 if (!shProg)
return;
  
 +   /* The ARB_get_program_binary spec says:
 +*
 +* If length is NULL, then no length is returned.
 +*
 +* Ensure that length always points to valid storage to avoid multiple 
 NULL
 +* pointer checks below.
 +*/
 +   if (length != NULL)
 +  *length = length_dummy;
 +
Is that supposed to read

 if (length == NULL)
 length = length_dummy;

?

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Finishing make distcheck

2014-12-15 Thread Julien Cristau 
On Mon, Dec 15, 2014 at 10:46:25 +, Emil Velikov wrote:

 On 12/12/14 22:41, Julien Cristau wrote:
  On Thu, Dec 11, 2014 at 09:02:11 +, Emil Velikov wrote:
  
   * Don't ship anything but a tar.xz tarball.
  Linux, *BSD and WindowsXP+ have/ship programs that support the format
  for more than 5 years.
 
  FWIW I'd appreciate if you kept the tar.gz.
  
 Can you please share what's the reason behind your request ?
 
 Planning to send out let's vote, and Cc a maintainer or two from the
 major 4-5 distros. Having some ideas why X or Y is desired/needed is
 always a plus.
 
The traditional debian source package format only does gz, and the newer
format comes with other drawbacks that I'd rather avoid.  I could always
repack, but since I expect the cost of keeping gz to be close to 0, I
thought I'd ask.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Finishing make distcheck

2014-12-12 Thread Julien Cristau 
On Thu, Dec 11, 2014 at 09:02:11 +, Emil Velikov wrote:

  * Don't ship anything but a tar.xz tarball.
 Linux, *BSD and WindowsXP+ have/ship programs that support the format
 for more than 5 years.
 
FWIW I'd appreciate if you kept the tar.gz.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 10.3.1

2014-10-13 Thread Julien Cristau 
On Mon, Oct 13, 2014 at 00:38:25 +0100, Emil Velikov wrote:

 Mesa 10.3.1 has been released. Mesa 10.3.1 is a bug fix release
 fixing bugs since the 10.3 release, (see below for a list of
 changes).
 
 The tag in the git repository for Mesa 10.3.1 is 'mesa-10.3.1'.
 
Hi Emil,

I'm not seeing that tag on the 10.3 branch.

Cheers,
Julien


signature.asc
Description: Digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Revert configure: ask vdpau.pc for the default location of the vdpau drivers

2014-10-12 Thread Julien Cristau 
On Tue, Sep 30, 2014 at 01:33:08 +0100, Emil Velikov wrote:

 On 29/09/14 17:24, Matt Turner wrote:
  On Mon, Sep 29, 2014 at 9:16 AM, Emil Velikov emil.l.veli...@gmail.com 
  wrote:
  So all in all we have the following:
 
  Some distributions/people choose odd location of the modules. Which
  can lead to the system (vdpau/omx) looking at the wrong place for the
  backends, i.e. not working. One can consider that there is no way to
  override the module location at runtime.
  
  Do we have more specifics? If they're doing something stupid and it
  breaks, they typically get to keep the pieces.
  
  Debian/Ubuntu install to /usr/lib/x86_64-linux-gnu/vdpau/? Isn't
  ${libdir} just /usr/lib/x86_64-linux-gnu/ in that case?
  
 Hmm I was under the impression that ${libdir} and
 /usr/lib/x86_64-linux-gnu/ are different things. Can I consider you as a
 volunteer for the following, even if the chances of it happening are zero ?
 
${libdir} is /usr/lib/x86_64-linux-gnu.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i915: Fix up intelInitScreen2 for DRI3

2014-07-09 Thread Julien Cristau 
On Thu, Jul  3, 2014 at 22:13:53 +0200, Adel Gadllah wrote:

 Commit 442442026eb updated both i915 and i965 for DRI3 support,
 but one check in intelInitScreen2 was missed for i915 causing crashes
 when trying to use i915 with DRI3.
 
 So fix that up.
 
 Reported-by: Igor Gnatenko i.gnatenko.br...@gmail.com
 Tested-by: František Zatloukal zatloukal.franti...@gmail.com
 Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1115323
 Cc: 10.2 mesa-sta...@lists.freedesktop.org
 Signed-off-by: Adel Gadllah adel.gadl...@gmail.com

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754297

Tested-by: Dirk Griesbach spamt...@freenet.de

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH demos 1/2] demos: Fix make distcheck

2014-07-05 Thread Julien Cristau 
On Fri, Jul  4, 2014 at 11:10:22 +0200, Andreas Boll wrote:

 Signed-off-by: Andreas Boll andreas.boll@gmail.com
 ---
  src/xdemos/Makefile.am | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 

On Fri, Jul  4, 2014 at 11:10:23 +0200, Andreas Boll wrote:

 Matches behavior with action-if-not-given
 
 Signed-off-by: Andreas Boll andreas.boll@gmail.com
 ---
  configure.ac | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)
 
for the series:
Reviewed-by: Julien Cristau jcris...@debian.org

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: correctly set LD_NO_UNDEFINED

2014-05-13 Thread Julien Cristau 
On Tue, May 13, 2014 at 01:36:28 +0100, Emil Velikov wrote:

 Commit 11623be934f85 was meant to have this hunk, which
 I accidently dropped during git rebase.
 
 Cc: 10.2 mesa-sta...@lists.freedesktop.org
 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

Reviewed-by: Julien Cristau jcris...@debian.org

Thanks for the quick fix.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] automake: don't enable -Wl, --no-undefined on OpenBSD

2014-05-12 Thread Julien Cristau 
On Thu, Apr  3, 2014 at 15:46:01 +1100, Jonathan Gray wrote:

 OpenBSD does not have DT_NEEDED entries for libc by design,
 over concerns how the symbols would be referenced after
 changing the major version of the library.
 
 So avoid -no-undefined checks on OpenBSD as they will fail.
 
 v2: don't include the -no-undefined libtool option in the variable
 and change -Wl,--no-undefined references in Automake.inc as well.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76856
 Signed-off-by: Jonathan Gray j...@jsg.id.au
 ---
  configure.ac| 13 +
  src/egl/main/Makefile.am|  2 +-
  src/egl/wayland/wayland-egl/Makefile.am |  2 +-
  src/gallium/Automake.inc|  6 +++---
  src/gallium/targets/egl-static/Makefile.am  |  2 +-
  src/gallium/targets/gbm/Makefile.am |  2 +-
  src/gallium/targets/libgl-xlib/Makefile.am  |  2 +-
  src/gallium/targets/opencl/Makefile.am  |  2 +-
  src/gallium/targets/osmesa/Makefile.am  |  2 +-
  src/gallium/targets/pipe-loader/Makefile.am |  2 +-
  src/gallium/targets/xa/Makefile.am  |  2 +-
  src/gbm/Makefile.am |  2 +-
  src/glx/Makefile.am |  2 +-
  src/mapi/es1api/Makefile.am |  2 +-
  src/mapi/es2api/Makefile.am |  2 +-
  src/mapi/shared-glapi/Makefile.am   |  2 +-
  src/mapi/vgapi/Makefile.am  |  2 +-
  src/mesa/drivers/osmesa/Makefile.am |  2 +-
  src/mesa/drivers/x11/Makefile.am|  2 +-
  19 files changed, 33 insertions(+), 20 deletions(-)
 
Hi,

it looks like the committed version of this change doesn't include the
configure.ac hunk.  That makes it rather less useful.  Did it get lost
somehow?

http://cgit.freedesktop.org/mesa/mesa/commit?id=11623be934f8573910484de2a5fb50c95f0a1d44

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gbm: make 'devices' array static

2014-03-03 Thread Julien Cristau 
It's only used in this one file as far as I can tell, and exporting a
symbol named 'devices' from a shared library is a recipe for trouble.
---
 src/gbm/main/gbm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index b057386..30785a6 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -43,7 +43,7 @@
 
 #define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0]))
 
-struct gbm_device *devices[16];
+static struct gbm_device *devices[16];
 
 static int device_num = 0;
 
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm: make 'devices' array static

2014-03-03 Thread Julien Cristau 
On Mon, Mar  3, 2014 at 17:21:15 +, Emil Velikov wrote:

 On 03/03/14 16:41, Julien Cristau wrote:
  It's only used in this one file as far as I can tell, and exporting a
  symbol named 'devices' from a shared library is a recipe for trouble.
 Hmm did you really get the 'devices' exported symbol, or did you notice
 this while going through the code ? Either way this looks good afaict
 
The former:
$ objdump -T /usr/lib/x86_64-linux-gnu/libgbm.so.1 | grep devices
00206360 gDO .bss   0080  Basedevices

 Reviewed-by: Emil Velikov emil.l.veli...@gmail.com

Thanks.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gbm: make 'devices' array static

2014-03-03 Thread Julien Cristau 
On Mon, Mar  3, 2014 at 17:29:56 +, Emil Velikov wrote:

 On 03/03/14 17:23, Julien Cristau wrote:
  On Mon, Mar  3, 2014 at 17:21:15 +, Emil Velikov wrote:
  
  On 03/03/14 16:41, Julien Cristau wrote:
  It's only used in this one file as far as I can tell, and exporting a
  symbol named 'devices' from a shared library is a recipe for trouble.
  Hmm did you really get the 'devices' exported symbol, or did you notice
  this while going through the code ? Either way this looks good afaict
 
  The former:
  $ objdump -T /usr/lib/x86_64-linux-gnu/libgbm.so.1 | grep devices
  00206360 gDO .bss   0080  Basedevices
  
 I'm guessing that this is from 10.1-rcx or earlier. All of the libgbm
 exported symbol mayhem is resolved in master. A few other libraries have
 been updated as well :-)
 
Right, I noticed the issue with at least 9.2, 10.0 and 10.1-rc.  Good to
know it's improved in master.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium: fix build failure on powerpcspe

2014-03-02 Thread Julien Cristau 
From: Roland Stigge sti...@antcom.de

In the case of powerpc, mesa activates some altivec instructions
that are unknown on the powerpcspe architecture (see
https://wiki.debian.org/PowerPCSPEPort), causing a build failure as the
'vand' opcode is not recognized by the assembler.

This patch fixes this by preventing the PPC-specialcasing in case of
powerpcspe (__NO_FPRS__ is only defined there).

https://bugs.debian.org/695746
---
 src/gallium/include/pipe/p_config.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/include/pipe/p_config.h 
b/src/gallium/include/pipe/p_config.h
index d603681..8189a73 100644
--- a/src/gallium/include/pipe/p_config.h
+++ b/src/gallium/include/pipe/p_config.h
@@ -107,12 +107,14 @@
 #endif
 #endif
 
+#ifndef __NO_FPRS__
 #if defined(__ppc__) || defined(__ppc64__) || defined(__PPC__)
 #define PIPE_ARCH_PPC
 #if defined(__ppc64__) || defined(__PPC64__)
 #define PIPE_ARCH_PPC_64
 #endif
 #endif
+#endif
 
 #if defined(__s390x__)
 #define PIPE_ARCH_S390
-- 
1.9.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: link against -lLLVM to determine build type

2013-08-15 Thread Julien Cristau 
On Wed, Aug 14, 2013 at 09:46:44 -0700, Tom Stellard wrote:

 On Wed, Aug 14, 2013 at 09:08:55AM +0200, Maarten Lankhorst wrote:
  Op 14-08-13 04:37, Tom Stellard schreef:
   On Tue, Aug 13, 2013 at 05:53:52PM +0200, Maarten Lankhorst wrote:
   Fixes a build failure of 9.2 on ubuntu, because libLLVM-3.3.so is not 
   present in /usr/lib/llvm-3.2/lib.
  
   I'm trying to understand the problem here, could you give a little more
   information about how Ubuntu packages LLVM?  Where are the LLVM
   libraries installed and what does llvm-config --libdir --ldflags report?
  libLLVM-3.3.so gets installed in /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so,
  there is no /usr/lib/llvm-3.2/lib/libLLVM-3.3.so
  All the other libs still get installed to /usr/lib/llvm-3.3/lib.
  
  ~$ llvm-config-3.3 --libdir --ldflags
  /usr/lib/llvm-3.3/lib
  -L/usr/lib/llvm-3.3/lib  -lpthread -lffi -ldl -lm
 
 So, if /usr/lib/x86_64-linux-gnu/ is not in the ldflags, then how will
 the linker find it?
 
It's in the default search path.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly

2012-08-23 Thread Julien Cristau 
On Sat, Jul 28, 2012 at 13:04:56 +0200, Julien Cristau wrote:

 On Fri, Jul 20, 2012 at 11:09:19 +0200, Julien Cristau wrote:
 
  From: Julien Cristau julien.cris...@logilab.fr
  
  We were stomping on the caller's buffer by ignoring their alignment
  requests and other pixel store modes.  This patch makes the USE_XCB path 
  match
  the older one more closely.
  
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059
  
  Signed-off-by: Julien Cristau julien.cris...@logilab.fr
  ---
  v2: add explicit bugzilla reference to commit message, drop unused
  assignment
  
   src/mapi/glapi/gen/glX_proto_send.py |   35 
  -
   1 files changed, 25 insertions(+), 10 deletions(-)
  
 Ping?
 
Ping?

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/3] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly

2012-07-28 Thread Julien Cristau 
On Fri, Jul 20, 2012 at 11:09:19 +0200, Julien Cristau wrote:

 From: Julien Cristau julien.cris...@logilab.fr
 
 We were stomping on the caller's buffer by ignoring their alignment
 requests and other pixel store modes.  This patch makes the USE_XCB path match
 the older one more closely.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059
 
 Signed-off-by: Julien Cristau julien.cris...@logilab.fr
 ---
 v2: add explicit bugzilla reference to commit message, drop unused
 assignment
 
  src/mapi/glapi/gen/glX_proto_send.py |   35 -
  1 files changed, 25 insertions(+), 10 deletions(-)
 
Ping?

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 1/3] glx: Simplify __glXReadPixelReply

2012-07-20 Thread Julien Cristau 
From: Julien Cristau julien.cris...@logilab.fr

Doing
size = reply.length * 4;
[...]
extra = 4 - (size  3);

is useless, size  3 will always be 0.

Signed-off-by: Julien Cristau julien.cris...@logilab.fr
---
v2: also change the copy in src/glx/apple

 src/glx/apple/glxreply.c |5 -
 src/mapi/glapi/gen/glX_proto_send.py |5 -
 2 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/src/glx/apple/glxreply.c b/src/glx/apple/glxreply.c
index f17ebe6..6234e3c 100644
--- a/src/glx/apple/glxreply.c
+++ b/src/glx/apple/glxreply.c
@@ -86,12 +86,7 @@ __glXReadPixelReply(Display * dpy, struct glx_context * gc, 
unsigned max_dim,
  __glXSetError(gc, GL_OUT_OF_MEMORY);
   }
   else {
- const GLint extra = 4 - (size  3);
-
  _XRead(dpy, buf, size);
- if (extra  4) {
-_XEatData(dpy, extra);
- }
 
  __glEmptyImage(gc, 3, width, height, depth, format, type, buf, dest);
  Xfree(buf);
diff --git a/src/mapi/glapi/gen/glX_proto_send.py 
b/src/mapi/glapi/gen/glX_proto_send.py
index bec0222..9068a61 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -246,12 +246,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context * 
gc, unsigned max_dim,
 __glXSetError(gc, GL_OUT_OF_MEMORY);
 }
 else {
-const GLint extra = 4 - (size  3);
-
 _XRead(dpy, buf, size);
-if ( extra  4 ) {
-_XEatData(dpy, extra);
-}
 
 __glEmptyImage(gc, 3, width, height, depth, format, type,
buf, dest);
-- 
1.7.2.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 2/3] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly

2012-07-20 Thread Julien Cristau 
From: Julien Cristau julien.cris...@logilab.fr

We were stomping on the caller's buffer by ignoring their alignment
requests and other pixel store modes.  This patch makes the USE_XCB path match
the older one more closely.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059

Signed-off-by: Julien Cristau julien.cris...@logilab.fr
---
v2: add explicit bugzilla reference to commit message, drop unused
assignment

 src/mapi/glapi/gen/glX_proto_send.py |   35 -
 1 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/src/mapi/glapi/gen/glX_proto_send.py 
b/src/mapi/glapi/gen/glX_proto_send.py
index 9068a61..029f8d9 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -673,16 +673,31 @@ generic_%u_byte( GLint rop, const void * ptr )
 
if f.needs_reply():
print '%s_reply_t *reply = %s_reply(c, 
%s, NULL);' % (xcb_name, xcb_name, xcb_request)
-   if output and f.reply_always_array:
-   print '(void)memcpy(%s, 
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name, 
xcb_name, output.get_base_type_string())
-
-   elif output and not f.reply_always_array:
-   if not output.is_image():
-   print 'if 
(%s_data_length(reply) == 0)' % (xcb_name)
-   print '
(void)memcpy(%s, reply-datum, sizeof(reply-datum));' % (output.name)
-   print 'else'
-   print '(void)memcpy(%s, 
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name, 
xcb_name, output.get_base_type_string())
-
+   if output:
+   if output.is_image():
+   [dim, w, h, d, junk] = 
output.get_dimensions()
+   if f.dimensions_in_reply:
+   w = reply-width
+   h = reply-height
+   d = reply-depth
+   if dim  2:
+   h = 1
+   else:
+   print '
if (%s == 0) { %s = 1; }' % (h, h)
+   if dim  3:
+   d = 1
+   else:
+   print '
if (%s == 0) { %s = 1; }' % (d, d)
+
+   print '
__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d, 
output.img_format, output.img_type, xcb_name, output.name)
+   else:
+   if f.reply_always_array:
+   print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' % 
(output.name, xcb_name, xcb_name, output.get_base_type_string())
+   else:
+   print 'if 
(%s_data_length(reply) == 0)' % (xcb_name)
+   print '
(void)memcpy(%s, reply-datum, sizeof(reply-datum));' % (output.name)
+   print 'else'
+   print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' % 
(output.name, xcb_name, xcb_name, output.get_base_type_string())
 
if f.return_type != 'void':
print 'retval = reply-ret_val;'
-- 
1.7.2.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] glx: drop unused 'dim' argument from __glEmptyImage

2012-07-20 Thread Julien Cristau 
From: Julien Cristau julien.cris...@logilab.fr

Suggested-by: Ian Romanick i...@freedesktop.org
Signed-off-by: Julien Cristau julien.cris...@logilab.fr
---
 src/glx/apple/glxreply.c |2 +-
 src/glx/glxclient.h  |2 +-
 src/glx/pixel.c  |2 +-
 src/glx/singlepix.c  |8 
 src/mapi/glapi/gen/glX_proto_send.py |4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/glx/apple/glxreply.c b/src/glx/apple/glxreply.c
index 6234e3c..db0817b 100644
--- a/src/glx/apple/glxreply.c
+++ b/src/glx/apple/glxreply.c
@@ -88,7 +88,7 @@ __glXReadPixelReply(Display * dpy, struct glx_context * gc, 
unsigned max_dim,
   else {
  _XRead(dpy, buf, size);
 
- __glEmptyImage(gc, 3, width, height, depth, format, type, buf, dest);
+ __glEmptyImage(gc, width, height, depth, format, type, buf, dest);
  Xfree(buf);
   }
}
diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
index f8ae450..6d7fc8d 100644
--- a/src/glx/glxclient.h
+++ b/src/glx/glxclient.h
@@ -718,7 +718,7 @@ extern void __glFillMap2d(GLint, GLint, GLint, GLint, GLint,
 ** Empty an image out of the reply buffer into the clients memory applying
 ** the pack modes to pack back into the clients requested format.
 */
-extern void __glEmptyImage(struct glx_context *, GLint, GLint, GLint, GLint, 
GLenum,
+extern void __glEmptyImage(struct glx_context *, GLint, GLint, GLint, GLenum,
GLenum, const GLubyte *, GLvoid *);
 
 
diff --git a/src/glx/pixel.c b/src/glx/pixel.c
index d508d62..15a5ed5 100644
--- a/src/glx/pixel.c
+++ b/src/glx/pixel.c
@@ -388,7 +388,7 @@ EmptyBitmap(struct glx_context * gc, GLint width, GLint 
height,
 */
 /* ARGSUSED */
 void
-__glEmptyImage(struct glx_context * gc, GLint dim, GLint width, GLint height,
+__glEmptyImage(struct glx_context * gc, GLint width, GLint height,
GLint depth, GLenum format, GLenum type,
const GLubyte * sourceImage, GLvoid * userdata)
 {
diff --git a/src/glx/singlepix.c b/src/glx/singlepix.c
index d8a7166..4c85cf0 100644
--- a/src/glx/singlepix.c
+++ b/src/glx/singlepix.c
@@ -80,7 +80,7 @@ __indirect_glGetSeparableFilter(GLenum target, GLenum format, 
GLenum type,
   }
   else {
  __GLX_SINGLE_GET_CHAR_ARRAY(((char *) rowBuf), widthsize);
- __glEmptyImage(gc, 1, width, 1, 1, format, type, rowBuf, row);
+ __glEmptyImage(gc, width, 1, 1, format, type, rowBuf, row);
  Xfree((char *) rowBuf);
   }
   colBuf = (GLubyte *) Xmalloc(heightsize);
@@ -94,7 +94,7 @@ __indirect_glGetSeparableFilter(GLenum target, GLenum format, 
GLenum type,
   }
   else {
  __GLX_SINGLE_GET_CHAR_ARRAY(((char *) colBuf), heightsize);
- __glEmptyImage(gc, 1, height, 1, 1, format, type, colBuf, column);
+ __glEmptyImage(gc, height, 1, 1, format, type, colBuf, column);
  Xfree((char *) colBuf);
   }
}
@@ -174,7 +174,7 @@ void gl_dispatch_stub_GetSeparableFilterEXT (GLenum target, 
GLenum format,
   _XEatData(dpy, extra);
}
 
-   __glEmptyImage(gc, 1, width, 1, 1, format, type, buf, row);
+   __glEmptyImage(gc, width, 1, 1, format, type, buf, row);
 
extra = 4 - (heightsize  3);
_XRead(dpy, (char *) buf, heightsize);
@@ -182,7 +182,7 @@ void gl_dispatch_stub_GetSeparableFilterEXT (GLenum target, 
GLenum format,
   _XEatData(dpy, extra);
}
 
-   __glEmptyImage(gc, 1, height, 1, 1, format, type, buf, column);
+   __glEmptyImage(gc, height, 1, 1, format, type, buf, column);
 
Xfree((char *) buf);
 }
diff --git a/src/mapi/glapi/gen/glX_proto_send.py 
b/src/mapi/glapi/gen/glX_proto_send.py
index 029f8d9..acf603a 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -248,7 +248,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context * gc, 
unsigned max_dim,
 else {
 _XRead(dpy, buf, size);
 
-__glEmptyImage(gc, 3, width, height, depth, format, type,
+__glEmptyImage(gc, width, height, depth, format, type,
buf, dest);
 Xfree(buf);
 }
@@ -689,7 +689,7 @@ generic_%u_byte( GLint rop, const void * ptr )
else:
print '
if (%s == 0) { %s = 1; }' % (d, d)
 
-   print '
__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d, 
output.img_format, output.img_type, xcb_name, output.name)
+   print '
__glEmptyImage(gc, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d, 
output.img_format, output.img_type, xcb_name, output.name

[Mesa-dev] [PATCH 2/2] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly (#52059)

2012-07-19 Thread Julien Cristau 
From: Julien Cristau julien.cris...@logilab.fr

We were stomping on the caller's buffer by ignoring their alignment
requests.  This patch makes the USE_XCB path match the older one more
closely.

Signed-off-by: Julien Cristau julien.cris...@logilab.fr
---
 src/mapi/glapi/gen/glX_proto_send.py |   36 -
 1 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/src/mapi/glapi/gen/glX_proto_send.py 
b/src/mapi/glapi/gen/glX_proto_send.py
index 9068a61..40cb05d 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -673,16 +673,32 @@ generic_%u_byte( GLint rop, const void * ptr )
 
if f.needs_reply():
print '%s_reply_t *reply = %s_reply(c, 
%s, NULL);' % (xcb_name, xcb_name, xcb_request)
-   if output and f.reply_always_array:
-   print '(void)memcpy(%s, 
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name, 
xcb_name, output.get_base_type_string())
-
-   elif output and not f.reply_always_array:
-   if not output.is_image():
-   print 'if 
(%s_data_length(reply) == 0)' % (xcb_name)
-   print '
(void)memcpy(%s, reply-datum, sizeof(reply-datum));' % (output.name)
-   print 'else'
-   print '(void)memcpy(%s, 
%s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name, 
xcb_name, output.get_base_type_string())
-
+   if output:
+   if output.is_image():
+   [dim, w, h, d, junk] = 
output.get_dimensions()
+   if f.dimensions_in_reply:
+   w = reply-width
+   h = reply-height
+   d = reply-depth
+   if dim  2:
+   h = 1
+   else:
+   print '
if (%s == 0) { %s = 1; }' % (h, h)
+   if dim  3:
+   d = 1
+   else:
+   print '
if (%s == 0) { %s = 1; }' % (d, d)
+
+   print '
__glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d, 
output.img_format, output.img_type, xcb_name, output.name)
+   else:
+   s = output.size() / 
output.get_element_count()
+   if f.reply_always_array:
+   print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' % 
(output.name, xcb_name, xcb_name, output.get_base_type_string())
+   else:
+   print 'if 
(%s_data_length(reply) == 0)' % (xcb_name)
+   print '
(void)memcpy(%s, reply-datum, sizeof(reply-datum));' % (output.name)
+   print 'else'
+   print '
(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' % 
(output.name, xcb_name, xcb_name, output.get_base_type_string())
 
if f.return_type != 'void':
print 'retval = reply-ret_val;'
-- 
1.7.2.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] glapi/glx: Simplify __glXReadPixelReply

2012-07-19 Thread Julien Cristau 
From: Julien Cristau julien.cris...@logilab.fr

Doing
size = reply.length * 4;
[...]
extra = 4 - (size  3);

is useless, size  3 will always be 0.

Signed-off-by: Julien Cristau julien.cris...@logilab.fr
---
 src/mapi/glapi/gen/glX_proto_send.py |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/src/mapi/glapi/gen/glX_proto_send.py 
b/src/mapi/glapi/gen/glX_proto_send.py
index bec0222..9068a61 100644
--- a/src/mapi/glapi/gen/glX_proto_send.py
+++ b/src/mapi/glapi/gen/glX_proto_send.py
@@ -246,12 +246,7 @@ __glXReadPixelReply( Display *dpy, struct glx_context * 
gc, unsigned max_dim,
 __glXSetError(gc, GL_OUT_OF_MEMORY);
 }
 else {
-const GLint extra = 4 - (size  3);
-
 _XRead(dpy, buf, size);
-if ( extra  4 ) {
-_XEatData(dpy, extra);
-}
 
 __glEmptyImage(gc, 3, width, height, depth, format, type,
buf, dest);
-- 
1.7.2.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] glapi/glx: call __glEmptyImage if USE_XCB, not memcpy directly (#52059)

2012-07-19 Thread Julien Cristau 
On Thu, Jul 19, 2012 at 09:39:09 -0700, Ian Romanick wrote:

 On 07/19/2012 07:46 AM, Julien Cristau wrote:
 From: Julien Cristau julien.cris...@logilab.fr
 
 We were stomping on the caller's buffer by ignoring their alignment
 requests.  This patch makes the USE_XCB path match the older one more
 closely.
 
 Signed-off-by: Julien Cristau julien.cris...@logilab.fr
 
 Say
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52059
 
 here instead of mentioning the bug in the subject.
 
Will do.

[...]
 +print '
 __glEmptyImage(gc, 3, %s, %s, %s, %s, %s, %s_data(reply), %s);' % (w, h, d, 
 output.img_format, output.img_type, xcb_name, output.name)
 
 I was going to comment that 'dim' should be the second parameter to
 __glEmptyImage instead of hardcoding 3, but it looks like the dim
 parameter isn't used in __glEmptyImage.  I think I can recommend a
 follow-on patch. :)
 
Ack.

 +else:
 +s = output.size() / 
 output.get_element_count()
 
 I don't see where this variable is used.
 
Right, I'll drop it.

Thanks!

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] i965: Convert the build to using automake.

2012-01-15 Thread Julien Cristau 
On Thu, Jan 12, 2012 at 20:52:33 -0500, Matt Turner wrote:

 On Thu, Jan 12, 2012 at 7:08 PM, Eric Anholt e...@anholt.net wrote:
  This does introduce a warning by the automake build system, that the
  missing-symbols test build is non-portable.  That's true -- Mac OS X
  can't take something built as a loadable module and just link it as a
  library.  Of course, we aren't building this on OS X at all, so it
  would be nice to be able to suppress it, but I haven't found a way.
 
  Still, the build is going to be much quieter than we have ever had
  before, so I think this is a fair tradeoff until we find a way to shut
  that warning up.
  ---
 
 If you want to still put i965_dri.so into the lib/ directory, here's
 what I've done for libglsl.so:
 
 all-local: libglsl.la
 if test ! -f $(top_srcdir)/$(LIB_DIR)/libglsl.so; then \
 $(MKDIR_P) $(top_srcdir)/$(LIB_DIR); \
 ln .libs/libglsl.so $(top_srcdir)/$(LIB_DIR)/libglsl.so; \
 fi
 
libglsl.so in srcdir?  that sounds like it should be builddir instead.
Not that mesa builds out of tree so far, but maybe automake will let us
fix that.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx/dri2: Paper over errors in DRI2Connect when indirect

2011-06-09 Thread Julien Cristau 
On Thu, Jun  9, 2011 at 18:57:54 +1000, Christopher James Halse Rogers wrote:

 DRI2 will throw BadRequest for this when the client is not local, but
 DRI2 is an implementation detail and not something callers should have
 to know about.  Silently swallow errors in this case, and just propagate
 the failure through DRI2Connect's return code.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28125
 Signed-off-by: Christopher James Halse Rogers 
 christopher.halse.rog...@canonical.com
 ---
 
 This seems to have died a quiet death without actually getting applied.
 Kristian, was this what you had in mind?
 
  src/glx/dri2.c |9 +
  1 files changed, 9 insertions(+), 0 deletions(-)
 
 diff --git a/src/glx/dri2.c b/src/glx/dri2.c
 index adfd3d1..00adff2 100644
 --- a/src/glx/dri2.c
 +++ b/src/glx/dri2.c
 @@ -180,6 +180,15 @@ DRI2Error(Display *display, xError *err, XExtCodes 
 *codes, int *ret_code)
   err-minorCode == X_DRI2DestroyDrawable)
   return True;
  
 +/* If the server is non-local DRI2Connect will raise BadRequest.
 + * Swallow this so that DRI2Connect can signal this in its return code */
 +if (err-majorCode == codes-major_opcode 
 +err-minorCode == X_DRI2Connect 
 +err-errorCode == BadRequest) {
 + *ret_code = False;
 + return True;
 +}
 +
  return False;
  }
  
I tested something like this (without setting *ret_code though, so my
patch was probably wrong), seemed to work just fine.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] Add Alpha to the little-endian machines.

2011-05-06 Thread Julien Cristau 
On Fri, May  6, 2011 at 13:01:14 -0400, Matt Turner wrote:

 From: Jay Estabrook jay.estabr...@gmail.com
 
 Reviewed-by: Matt Turner matts...@gmail.com
 Signed-off-by: Jay Estabrook jay.estabr...@gmail.com
 ---
  src/gallium/include/pipe/p_config.h |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/src/gallium/include/pipe/p_config.h 
 b/src/gallium/include/pipe/p_config.h
 index 74a1fa2..9e8ff6a 100644
 --- a/src/gallium/include/pipe/p_config.h
 +++ b/src/gallium/include/pipe/p_config.h
 @@ -99,6 +99,10 @@
  #endif
  #endif
  
 +#if defined(__alpha__)
 +#define PIPE_ARCH_ALPHA
 +#endif
 +
  #if defined(__PPC__)
  #define PIPE_ARCH_PPC
  #if defined(__PPC64__)
 @@ -111,7 +115,7 @@
   * Endian detection.
   */
  
 -#if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64)
 +#if defined(PIPE_ARCH_X86) || defined(PIPE_ARCH_X86_64) || 
 defined(PIPE_ARCH_ALPHA)
  #define PIPE_ARCH_LITTLE_ENDIAN
  #elif defined(PIPE_ARCH_PPC) || defined(PIPE_ARCH_PPC_64)
  #define PIPE_ARCH_BIG_ENDIAN

Is there any particular reason this can't do the following, at least on
glibc platforms?

#include endian.h

#if __BYTE_ORDER == __LITTLE_ENDIAN
# define PIPE_ARCH_LITTLE_ENDIAN
#elif __BYTE_ORDER == __BIG_ENDIAN
# define PIPE_ARCH_BIG_ENDIAN
#endif

Instead of having an always incomplete hardcoded list as detection...

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] Don't allow compilation if endianness isn't known

2011-05-06 Thread Julien Cristau 
On Fri, May  6, 2011 at 13:01:15 -0400, Matt Turner wrote:

 Signed-off-by: Matt Turner matts...@gmail.com
 ---
 
 PIPE_ARCH_UNKNOWN_ENDIAN is used no where else. All #else branches of
 #ifdef PIPE_ARCH_LITTLE assume big-endian. Not #error'ing out here
 only serves to allow bad things to happen.
 
I think this text should be part of the commit message.  Patch looks
like a good idea to me, fwiw.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] configure.ac: refuse to build r300g without LLVM

2011-04-26 Thread Julien Cristau 
On Sat, Apr 23, 2011 at 10:48:49 +0200, Marek Olšák wrote:

 On Fri, Apr 22, 2011 at 1:29 PM, Jose Fonseca jfons...@vmware.com wrote:
 
  The Mesa state tracker uses SWTNL for GL selection/feedback regardless of
  the driver. Some SPECviewperf viewsets and CAD apps use it. So using LLVM
  speeds up selection/feedback for all gallium drivers.
 
  We have only tested LLVM with x86/x86_64. So indeed, using it/requiring it
  on other platforms is not advisable.
 
 
 I take the first patch back. Here's an updated r300g patch that requires
 LLVM on x86 and x86_64 only:
 
 
 configure.ac: require LLVM to build r300g on x86 and x86_64
 
 diff --git a/configure.ac b/configure.ac
 index d8c50ce..1012ca5 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1780,9 +1780,16 @@ dnl Gallium Radeon r300g configuration
  dnl
  AC_ARG_ENABLE([gallium-r300],
  [AS_HELP_STRING([--enable-gallium-r300],
 -[build gallium r300 @:@default=DRI-only@:@])],
 +[build gallium r300 @:@default=build DRI driver only@:@])],
  [enable_gallium_r300=$enableval],
  [enable_gallium_r300=auto])
 +if test x$enable_gallium_r300 != xno; then
 +if test x$MESA_LLVM = x0; then
 +case $host_cpu in
 +i*86|x86_64) AC_MSG_ERROR([LLVM is required to build Gallium R300
 on x86 and x86_64]);;
 +esac
 +fi
 +fi
  if test x$enable_gallium_r300 = xauto; then
  GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS r300
  gallium_check_st radeon/drm dri-r300
 
 
AIUI it's not really required, it'll just be slow if built without llvm?
How much of that is specific to r300 as opposed to other gallium
drivers?  Shouldn't this be a warning instead of an error?

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/3] Only require libdrm if direct rendering is actually enabled

2011-02-16 Thread Julien Cristau 
On Wed, Feb 16, 2011 at 15:11:34 +, Jon TURNEY wrote:

 At the moment, libGL cannot be built --with-driver=dri --disable-driglx-direct
 on platforms which don't have libdrm.
 
 --with-driver=dri is the only way to build a libGL which supports indirect
 rendering.
 
 This patch set makes libdrm only required if --enable-driglx-direct is used,
 and makes --disable-driglx-direct the default on cygwin and hurd.
 
 (this patch set combines patches from fd.o bugs #27840 and #29460, updated for
 the current git master)
 
 Jon TURNEY (1):
   Disable direct rendering on Cygwin
 
 Samuel Thibault (1):
   Only require libdrm if direct rendering is actually enabled.
 
 nobled (1):
   Disable direct rendering on GNU/Hurd
 
For the series:
Reviewed-by: Julien Cristau jcris...@debian.org

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.

2011-01-31 Thread Julien Cristau 
On Sun, Jan 30, 2011 at 00:00:48 +0100, Henri Verbeet wrote:

 @@ -918,12 +921,15 @@ dri2CreateScreen(int screen, struct glx_display * priv)
 return psc-base;
  
  handle_error:
 +   if (psc-fd)
 +  close(psc-fd);

0 is a valid fd.  It might be better to initialize fd to -1 and check
for = 0 here.

 +   if (psc-driver)
 +  dlclose(psc-driver);
 Xfree(driverName);
 Xfree(deviceName);
 +   glx_screen_cleanup(psc-base);
 XFree(psc);
  
 -   /* FIXME: clean up here */
 -
 return NULL;
  }
  
Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glx: Fix leaks in DRI2 screen creation error paths.

2011-01-31 Thread Julien Cristau 
On Mon, Jan 31, 2011 at 18:18:22 +0100, Henri Verbeet wrote:

 The attached patch should do.

Looks good to me, thanks.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] glx: fix GLXChangeDrawableAttributesSGIX request

2011-01-26 Thread Julien Cristau 
xGLXChangeDrawableAttributesSGIXReq follows the GLXVendorPrivate header
with a drawable, number of attributes, and list of (type, value)
attribute pairs.  Don't forget to put the number of attributes in there.
I don't think this can ever have worked.

Signed-off-by: Julien Cristau jcris...@debian.org
---
 src/glx/glx_pbuffer.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 34892e8..6fc8433 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -117,7 +117,7 @@ ChangeDrawableAttribute(Display * dpy, GLXDrawable drawable,
else {
   xGLXVendorPrivateWithReplyReq *vpreq;
 
-  GetReqExtra(GLXVendorPrivateWithReply, 4 + (8 * num_attribs), vpreq);
+  GetReqExtra(GLXVendorPrivateWithReply, 8 + (8 * num_attribs), vpreq);
   output = (CARD32 *) (vpreq + 1);
 
   vpreq-reqType = opcode;
@@ -125,7 +125,8 @@ ChangeDrawableAttribute(Display * dpy, GLXDrawable drawable,
   vpreq-vendorCode = X_GLXvop_ChangeDrawableAttributesSGIX;
 
   output[0] = (CARD32) drawable;
-  output++;
+  output[1] = num_attribs;
+  output += 2;
}
 
(void) memcpy(output, attribs, sizeof(CARD32) * 2 * num_attribs);
-- 
1.7.2.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glx: fix request lengths

2011-01-23 Thread Julien Cristau 
We were sending too long requests for GLXChangeDrawableAttributes,
GLXGetDrawableAttributes, GLXDestroyPixmap and GLXDestroyWindow.

Signed-off-by: Julien Cristau jcris...@debian.org
---
 src/glx/glx_pbuffer.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index 34892e8..1de3e74 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -106,7 +106,7 @@ ChangeDrawableAttribute(Display * dpy, GLXDrawable drawable,
if ((priv-majorVersion  1) || (priv-minorVersion = 3)) {
   xGLXChangeDrawableAttributesReq *req;
 
-  GetReqExtra(GLXChangeDrawableAttributes, 8 + (8 * num_attribs), req);
+  GetReqExtra(GLXChangeDrawableAttributes, 8 * num_attribs, req);
   output = (CARD32 *) (req + 1);
 
   req-reqType = opcode;
@@ -297,7 +297,7 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
if (use_glx_1_3) {
   xGLXGetDrawableAttributesReq *req;
 
-  GetReqExtra(GLXGetDrawableAttributes, 4, req);
+  GetReq(GLXGetDrawableAttributes, req);
   req-reqType = opcode;
   req-glxCode = X_GLXGetDrawableAttributes;
   req-drawable = drawable;
@@ -435,7 +435,7 @@ DestroyDrawable(Display * dpy, GLXDrawable drawable, CARD32 
glxCode)
 
LockDisplay(dpy);
 
-   GetReqExtra(GLXDestroyPbuffer, 4, req);
+   GetReq(GLXDestroyPbuffer, req);
req-reqType = opcode;
req-glxCode = glxCode;
req-pbuffer = (GLXPbuffer) drawable;
-- 
1.7.2.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 7.10 release

2011-01-08 Thread Julien Cristau 
On Sat, Jan  8, 2011 at 17:00:54 +0100, Sebastian H. wrote:

 make then stopped like this
 
 gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
 -I../../../../../include -I../../../../../src/mapi
 -I../../../../../src/mesa -I../../../../../src/egl/main
 -I../../../../../src/egl/drivers/dri -I/usr/include/libdrm-g -O2
 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
 -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS
 -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
 -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
 -DFEATURE_GL=1 -I../intel -DI915 -DDRM_VBLANK_FLIP=DRM_VBLANK_FLIP
 intel_batchbuffer.c -o intel_batchbuffer.o
 intel_batchbuffer.c: In function ‘do_flush_locked’:
 intel_batchbuffer.c:101: error: ‘I915_EXEC_BLT’ undeclared (first use in
 this function)
 intel_batchbuffer.c:101: error: (Each undeclared identifier is reported
 only once
 intel_batchbuffer.c:101: error: for each function it appears in.)

You need a newer libdrm.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] osmesa: static linking of talloc

2011-01-04 Thread Julien Cristau 
On Sun, Oct 24, 2010 at 13:23:28 +0200, Tormod Volden wrote:

 Commit 5a3ac74 added $(TALLOC_LIBS) to the mklib call in
 src/mesa/drivers/osmesa/Makefile and this breaks static builds on
 Linux since ar barfs on -ltalloc. I have been looking at different
 ways of dealing with this without finding any elegant solution. We can
 change configure.ac to set TALLOC_LIBS to libtalloc.a for static
 builds, but ar needs the full path and something like this does not
 look pretty in there:
 TALLOC_LIBS=`$PKG_CONFIG --variable=libdir talloc`/libtalloc.a
 
 Alternatively, I have a mklib hack to translate -lfoo into libfoo.a
 (searched for in different paths, also ugly) for static builds. I
 wonder if libtool can do this in a clever way instead, but I don't
 know libtool well enough.
 
 Finally, maybe reverting 5a3ac74 is better. For shared libs,
 TALLOC_LIBS is already added to OSLIB_MESA_DEPS in configure.ac. For
 static builds, configure.ac explicitly says to not link libraries
 only link libraries with osmesa if shared. So this is in
 contradiction to 5a3ac74 AFAICS. But I am probably missing something,
 especially outside my own use case.
 
Revert sounds correct to me if we already get -ltalloc from
OSLIB_MESA_DEPS for the shared build.  The static build doesn't need it.
Cc:ing ajax and Orion.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH:mesa-demos] Allow builders to specify GLEW_CFLAGS GLEW_LIBS

2010-12-30 Thread Julien Cristau 
On Thu, Dec 30, 2010 at 10:27:14 -0700, tom fogal wrote:

 Isn't this going to mean that GLEW's w/o the .pc file cannot be used?

I don't think so.  If the .pc isn't found and you didn't pass
GLEW_{CFLAGS,LIBS}, it'll look for GL/glew.h and -lGLEW directly.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] Makefile: don't include the same files twice in the tarball

2010-11-13 Thread Julien Cristau 
src/mesa/drivers/dri/*/*/*.[chS] is a superset of
src/mesa/drivers/dri/*/server/*.[ch] and
src/mesa/drivers/dri/common/xmlpool/*.[ch].
include/GL/internal/glcore.h is already in MAIN_FILES, no need for it in
DRI_FILES too.  src/glx/Makefile was listed twice.

Signed-off-by: Julien Cristau jcris...@debian.org
---
This patch is against 7.9, I haven't checked if master needs it too.
See http://lists.debian.org/debian-x/2010/11/msg00556.html and
http://lists.debian.org/debian-x/2010/11/msg00562.html for the
rationale.

 Makefile |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index b8069f9..b13ed33 100644
--- a/Makefile
+++ b/Makefile
@@ -347,23 +347,19 @@ GALLIUM_FILES = \
 
 DRI_FILES = \
$(DIRECTORY)/include/GL/internal/dri_interface.h\
-   $(DIRECTORY)/include/GL/internal/glcore.h   \
$(DIRECTORY)/include/GL/internal/sarea.h\
$(DIRECTORY)/src/glx/Makefile   \
-   $(DIRECTORY)/src/glx/Makefile   \
$(DIRECTORY)/src/glx/*.[ch] \
$(DIRECTORY)/src/mesa/drivers/dri/Makefile  \
$(DIRECTORY)/src/mesa/drivers/dri/Makefile.template \
$(DIRECTORY)/src/mesa/drivers/dri/dri.pc.in \
-   $(DIRECTORY)/src/mesa/drivers/dri/common/xmlpool/*.[ch] \
$(DIRECTORY)/src/mesa/drivers/dri/common/xmlpool/*.po   \
$(DIRECTORY)/src/mesa/drivers/dri/*/*.[chS] \
$(DIRECTORY)/src/mesa/drivers/dri/*/*.cpp   \
$(DIRECTORY)/src/mesa/drivers/dri/*/*/*.[chS]   \
$(DIRECTORY)/src/mesa/drivers/dri/*/Makefile\
$(DIRECTORY)/src/mesa/drivers/dri/*/*/Makefile  \
-   $(DIRECTORY)/src/mesa/drivers/dri/*/Doxyfile\
-   $(DIRECTORY)/src/mesa/drivers/dri/*/server/*.[ch]
+   $(DIRECTORY)/src/mesa/drivers/dri/*/Doxyfile
 
 SGI_GLU_FILES = \
$(DIRECTORY)/src/glu/Makefile   \
-- 
1.7.2.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Disappearing patches

2010-10-19 Thread Julien Cristau 
On Tue, Oct 19, 2010 at 13:31:35 +0200, Thomas Hellstrom wrote:

 Hi!
 
 I've been trying to send a patch to mesa-dev a couple of times using
 git send-email, but the message never makes it to the list. Am I the
 only one having trouble with this?
 
It did make it to the list, both times, as far as I can tell.
http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003575.html
http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003619.html

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Disappearing patches

2010-10-19 Thread Julien Cristau 
On Tue, Oct 19, 2010 at 14:15:44 +0200, Thomas Hellstrom wrote:

 On 10/19/2010 01:55 PM, Julien Cristau wrote:
 On Tue, Oct 19, 2010 at 13:31:35 +0200, Thomas Hellstrom wrote:
 
 Hi!
 
 I've been trying to send a patch to mesa-dev a couple of times using
 git send-email, but the message never makes it to the list. Am I the
 only one having trouble with this?
 
 It did make it to the list, both times, as far as I can tell.
 http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003575.html
 http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003619.html
 
 Cheers,
 Julien
 Hmm, Thanks,
 
 You're obviously right. I wonder whether it might be the VMware spam
 filter automatically
 classifying my patches as crap when the list sends them back...
 
It could be mailman deciding that since you're the sender you don't want
them through the list?  IIRC there's an option for that in the
subscription preferences.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] cflags mess with llvm builds

2010-09-24 Thread Julien Cristau 
On Fri, Sep 24, 2010 at 14:06:51 +0200, Xavier Chantry wrote:

 When gallium llvm is enabled, configure.ac does the following :
 LLVM_CFLAGS=`$LLVM_CONFIG --cflags`
 
 This is the result on my system :
 -I/usr/include  -DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
 -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC
 
I'd argue that that's a bug in llvm-config, it has no business telling
you what optimisation level to use, or defining random macros.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Xlib GL needs -ltalloc

2010-08-27 Thread Julien Cristau 
On Fri, Aug 27, 2010 at 15:24:45 +0100, Jon TURNEY wrote:

 diff --git a/src/mesa/drivers/osmesa/Makefile 
 b/src/mesa/drivers/osmesa/Makefile
 index 091e6f6..fb70790 100644
 --- a/src/mesa/drivers/osmesa/Makefile
 +++ b/src/mesa/drivers/osmesa/Makefile
 @@ -38,7 +38,7 @@ default: $(TOP)/$(LIB_DIR)/$(OSMESA_LIB_NAME)
  $(TOP)/$(LIB_DIR)/$(OSMESA_LIB_NAME): $(OBJECTS) $(CORE_MESA)
   $(MKLIB) -o $(OSMESA_LIB) -linker '$(CC)' -ldflags '$(LDFLAGS)' \

-linker '$(CXX)'?

   -major $(MESA_MAJOR) -minor $(MESA_MINOR) -patch $(MESA_TINY) \
 - -install $(TOP)/$(LIB_DIR) $(MKLIB_OPTIONS) \
 + -install $(TOP)/$(LIB_DIR) -cplusplus $(MKLIB_OPTIONS) \
   -id $(INSTALL_LIB_DIR)/lib$(OSMESA_LIB).$(MESA_MAJOR).dylib \
   $(OSMESA_LIB_DEPS) $(OBJECTS) $(CORE_MESA)
  

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Fix kFreeBSD build

2010-07-18 Thread Julien Cristau 
On Sun, Jul 18, 2010 at 08:59:23 -0700, Corbin Simpson wrote:

 I didn't ack the earlier version of the patch because it had no testers. Has
 this been tested?
 
It's been used in debian's mesa packages since April 2009.
So Acked-by: Julien Cristau jcris...@debian.org

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Bug#585618: [PATCH 1/6] pipe: Detect FreeBSD better

2010-07-18 Thread Julien Cristau 
On Thu, Jun 24, 2010 at 01:07:17 -0700, Corbin Simpson wrote:

 On Wed, Jun 23, 2010 at 6:31 PM, nobled nob...@dreamwidth.org wrote:
  Taking advice from the Debian BSD porting guide:
  http://glibc-bsd.alioth.debian.org/porting/PORTING
 
  This should help fix Debian bug #585618 (gallium build failure).
  ---
   src/gallium/include/pipe/p_config.h |    2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  diff --git a/src/gallium/include/pipe/p_config.h
  b/src/gallium/include/pipe/p_config.h
  index b81702a..68025fa 100644
  --- a/src/gallium/include/pipe/p_config.h
  +++ b/src/gallium/include/pipe/p_config.h
  @@ -128,7 +128,7 @@
   #define PIPE_OS_UNIX
   #endif
 
  -#if defined(__FreeBSD__)
  +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
   #define PIPE_OS_FREEBSD
   #define PIPE_OS_BSD
   #define PIPE_OS_UNIX
  --
  1.5.4.3
 
 Looks reasonable; does this actually work for you? I'd like somebody
 to test first.
 
I verified that this builds on a kfreebsd system on top of 7.8.2, and
looking at the differences between PIPE_OS_LINUX and PIPE_OS_{,FREE}BSD
in the code this seems reasonable, so
Reviewed-by: Julien Cristau jcris...@debian.org

Maybe also consider:

diff --git a/src/gallium/auxiliary/rtasm/rtasm_execmem.c 
b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
index 65d5ce7..bd84532 100644
--- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
+++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
@@ -37,7 +37,7 @@
 
 #include rtasm_execmem.h
 
-#if defined(PIPE_OS_BSD)
+#ifndef MAP_ANONYMOUS
 #define MAP_ANONYMOUS MAP_ANON
 #endif
 

(the kfreebsd glibc headers define MAP_ANONYMOUS to MAP_ANON already, so
this one shouldn't be strictly necessary)

Cheers,
Julien


signature.asc
Description: Digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Bug#585618: [PATCH 2/6] pipe: Add PIPE_OS_HURD

2010-06-24 Thread Julien Cristau 
On Thu, Jun 24, 2010 at 01:08:03 -0700, Corbin Simpson wrote:

 On Wed, Jun 23, 2010 at 6:31 PM, nobled nob...@dreamwidth.org wrote:
  One tiny step toward porting Gallium to the GNU/Hurd kernel
  (and fixing Debian bug #585618).
  ---
   src/gallium/include/pipe/p_config.h |    5 +
   1 files changed, 5 insertions(+), 0 deletions(-)
 
  diff --git a/src/gallium/include/pipe/p_config.h
  b/src/gallium/include/pipe/p_config.h
  index 68025fa..b077933 100644
  --- a/src/gallium/include/pipe/p_config.h
  +++ b/src/gallium/include/pipe/p_config.h
  @@ -146,6 +146,11 @@
   #define PIPE_OS_UNIX
   #endif
 
  +#if defined(__GNU__)
  +#define PIPE_OS_HURD
  +#define PIPE_OS_UNIX
  +#endif
  +
   #if defined(__sun)
   #define PIPE_OS_SOLARIS
   #define PIPE_OS_UNIX
  --
  1.5.4.3
 
 This is only defined on HURD, right? It's not part of the GCC-specific 
 defines?
 
Correct.

Cheers,
Julien


signature.asc
Description: Digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] dri loader ABI change between mesa 7.7 and 7.8

2010-06-22 Thread Julien Cristau 
On Mon, Jun 21, 2010 at 17:23:25 -0600, Brian Paul wrote:

 Julien Cristau wrote:
 Hi,
 
 it seems that the dri loader ABI changed between mesa 7.7 and 7.8.
 Drivers from 7.7 reference a _glapi_set_warning_func symbol which
 doesn't seem to be exported by the 7.8 libGL, so the new libGL can't
 load the old drivers.  Was this change intentional?  What is the
 intended stability of that interface?
 
 This was fixed with commit f1381880a8e0e0cdd96c4c725ff35a28b250b09d
 and should be in Mesa 7.8.2
 
Ah, thanks, I should have checked.

Cheers,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Bug 28280] Regression in mesa branches 7.7/7.8: glXChooseVisual fails to find visual

2010-06-02 Thread Julien Cristau 
On Sat, May 29, 2010 at 06:13:11 -0700, bugzilla-dae...@freedesktop.org wrote:

 https://bugs.freedesktop.org/show_bug.cgi?id=28280
 
 --- Comment #3 from Matthias Liertzer m_liert...@gmx.at 2010-05-29 06:13:11 
 PDT ---
 Created an attachment (id=35934)
  View: https://bugs.freedesktop.org/attachment.cgi?id=35934
  Review: https://bugs.freedesktop.org/review?bug=28280attachment=35934
 
 Patch backported from master branch
 
Can somebody please apply this regression fix to the 7.7 and 7.8
branches?  26a9b7e4c737c89b47844303bb7413ceab0280a5 can probably be
cherry-picked as-is to 7.8, but 7.7 has different paths so needs the
above backport.

Thanks,
Julien
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev