Re: [Mesa3d-dev] Mesa release for the end of March?
On Fri, 2010-02-19 at 14:05 -0800, Corbin Simpson wrote: > On Fri, Feb 19, 2010 at 11:14 AM, Brian Paul wrote: > > Guillem Jover wrote: > >> Hi! > >> > >> [ CCing Daniel Borca who used to work on 3dfx support in Mesa and > >> libglide, not sure though if he is around or interested anymore. ] > >> > >> On Thu, 2010-02-18 at 17:25:02 -0700, Brian Paul wrote: > >>> 3. I'm tempted to remove some old Mesa drivers such as glide, tdfx, > >>> allegro, ggi, dri/mga, dri/mach64. Maybe more. Any objections? > >> > >> Could the drivers for actual hardware (namely glide, tdfx, dri/mga > >> and dri/mach64) be exempted from removal? I at least still have cards > >> for those, not sure though how many users might be out there, but > >> whenever libglide has broken in Debian, I tend to receive bug reports, > >> so I'd assume there's still some. And it always saddens me a bit when > >> hardware support gets dropped in projects. > > > > I have/had no idea if the tdfx, glide, mga or mach64 drivers function > > anymore. If someone is actively using or testing the drivers I guess > > we could keep them, but I'd rather not otherwise. > > One of my co-workers, bless his soul, is digging out a PCI Voodoo3 for > my collection, so I can maintain tdfx. I don't know about glide. > > I am *not* testing mga; I don't have the right motherboard for it, sorry. mga continues to work surprisingly well, given it's age. I have a few G450 and an G550 here... robert. > mach64's DRM code was getting a once-over by somebody on either > dri-devel or LKML; maybe we could wait and see if somebody cares. > > ~ C. > -- Robert Noland 2Hip Networks -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Fix missing sl_pp_* and sl_cl_* symbols in all the dri drivers.
On Thu, 2009-12-24 at 04:48 -0800, Brian Paul wrote: > > On Wed, Dec 23, 2009 at 4:58 PM, Robert Noland wrote: > > > On Wed, 2009-12-23 at 16:49 -0700, Brian Paul wrote: > > >> OK, here's a patch for bin/mklib which should help on FreeBSD. It > > >> also puts some common code into new subroutines. > > >> > > >> Let me know if this does the trick. That seems to do it, thanks. robert. > > > Missing attachment? Or did I miss a commit? > > > > Hmm, trying the attachment again. > > OK, trying yet again. Something's goofy with my gmail. > > -Brian -- Robert Noland 2Hip Networks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Fix missing sl_pp_* and sl_cl_* symbols in all the dri drivers.
On Wed, 2009-12-23 at 16:49 -0700, Brian Paul wrote: > OK, here's a patch for bin/mklib which should help on FreeBSD. It > also puts some common code into new subroutines. > > Let me know if this does the trick. Missing attachment? Or did I miss a commit? robert. -- Robert Noland 2Hip Networks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Fix missing sl_pp_* and sl_cl_* symbols in all the dri drivers.
Signed-off-by: Robert Noland --- src/mesa/drivers/dri/Makefile.template |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/Makefile.template b/src/mesa/drivers/dri/Makefile.template index 39d25ce..39a23b7 100644 --- a/src/mesa/drivers/dri/Makefile.template +++ b/src/mesa/drivers/dri/Makefile.template @@ -2,6 +2,9 @@ MESA_MODULES = $(TOP)/src/mesa/libmesa.a +GLSL_MODULES = $(TOP)/src/glsl/cl/libglslcl.a \ + $(TOP)/src/glsl/pp/libglslpp.a + COMMON_GALLIUM_SOURCES = \ ../common/utils.c \ ../common/vblank.c \ @@ -71,7 +74,7 @@ $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) $(WINOBJ) Makefile \ $(TOP)/src/mesa/drivers/dri/Makefile.template $(MKLIB) -o $@ -noprefix -linker '$(CC)' -ldflags '$(LDFLAGS)' \ $(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) $(WINOBJ) \ - $(DRI_LIB_DEPS) + $(GLSL_MODULES) $(DRI_LIB_DEPS) $(TOP)/$(LIB_DIR)/$(LIBNAME): $(LIBNAME) -- 1.6.5.1 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: ERESTART is not returned to userland, at least not on FreeBSD
On Tue, 2009-12-01 at 10:17 +0100, Thomas Hellstrom wrote: > Jakob Bornecrantz wrote: > > On 1 dec 2009, at 00.24, Robert Noland wrote: > > > >> On Tue, 2009-12-01 at 10:37 +1100, Daniel Stone wrote: > >> > >>> On Mon, Nov 30, 2009 at 11:21:47AM -0600, Robert Noland wrote: > >>> > >>>> I've tried to ask linux folk if this is also true for linux, but the > >>>> answer is unclear at this time. > >>>> > >>> EINTR will be returned to userspace if the syscall needs to be > >>> restarted. > >>> > >> Ok, EINTR is already handled in drmIoctl() as is EAGAIN, so that > >> sounds > >> like my patch would be correct. > >> > > > > Hmm looks like we need to change bunch of stuff in ttm and the vmwgfx > > for that to be true. I still like to get Thomas comments on this > > before we do anything drastic. > > > > > Yes, there is some stuff we need to change here, really. > > As previously pointed out by people on the dri-devel list (Kristian > among others), if the linux kernel returns > -ERESTARTSYS, and the kernel cannot restart the system call AND there is > a signal pending, the kernel (not libc) will convert it to -EINTR and > return to user-space. -ERESTARTSYS may only be returned when there is a > signal pending. > > I'm not sure this is the case with -ERESTART. IIRC I've seen man pages > with kernel calls return -ERESTART, but I'm not sure at this point. Best > would be to test and see what happens. > > Having said that. I don't think we should change this *now*. If BSD > converts -ERESTART to -EINTR, that will get caught in drmCommandXXX and > functionality will be preserved. My current issue is that ERESTART isn't even defined in userspace, so if I enable gallium I have build failure. robert. > However, before pushing wmwgfx upstream, and before the Radeon > user-space interface is set in stone, we should change the TTM code to > return -ERESTARTSYS when a signal is pending, meaning that if it returns > to user-space, we'll get an -EINTR. At the same time we could apply the > suggested patch. If TTM is ported to BSD, and -ERESTARTSYS doesn't exist > in BST, the BSD version should return something that will appear as > -EINTR in user space. > > So to summarize: > > *) I don't think the patch is correct with the current linux wmw / ttm code. > *) We should change the ttm / vmw code ASAP so that the patch becomes > correct. When this is done, we should apply it. > > Thanks, > > Thomas > > > > > > > > > > > > Cheers Jakob. > > > > -- > > Join us December 9, 2009 for the Red Hat Virtual Experience, > > a free event focused on virtualization and cloud computing. > > Attend in-depth sessions from your desk. Your couch. Anywhere. > > http://p.sf.net/sfu/redhat-sfdev2dev > > ___ > > Mesa3d-dev mailing list > > Mesa3d-dev@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > > > -- Robert Noland 2Hip Networks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] gallium: ERESTART is not returned to userland, at least not on FreeBSD
On Tue, 2009-12-01 at 10:37 +1100, Daniel Stone wrote: > On Mon, Nov 30, 2009 at 11:21:47AM -0600, Robert Noland wrote: > > I've tried to ask linux folk if this is also true for linux, but the > > answer is unclear at this time. > > EINTR will be returned to userspace if the syscall needs to be restarted. Ok, EINTR is already handled in drmIoctl() as is EAGAIN, so that sounds like my patch would be correct. robert. > Cheers, > Daniel -- Robert Noland 2Hip Networks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] gallium: ERESTART is not returned to userland, at least not on FreeBSD
I've tried to ask linux folk if this is also true for linux, but the
answer is unclear at this time.
Signed-off-by: Robert Noland
---
.../winsys/drm/vmware/core/vmw_screen_ioctl.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/src/gallium/winsys/drm/vmware/core/vmw_screen_ioctl.c
b/src/gallium/winsys/drm/vmware/core/vmw_screen_ioctl.c
index 51e455f..f23b7c1 100644
--- a/src/gallium/winsys/drm/vmware/core/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/drm/vmware/core/vmw_screen_ioctl.c
@@ -260,9 +260,7 @@ vmw_ioctl_command(struct vmw_winsys_screen *vws, void
*commands, uint32_t size,
arg.commands = (unsigned long)commands;
arg.command_size = size;
- do {
- ret = drmCommandWrite(vws->ioctl.drm_fd, DRM_VMW_EXECBUF, &arg,
sizeof(arg));
- } while(ret == -ERESTART);
+ ret = drmCommandWrite(vws->ioctl.drm_fd, DRM_VMW_EXECBUF, &arg,
sizeof(arg));
if (ret) {
debug_printf("%s error %s.\n", __FUNCTION__, strerror(-ret));
}
@@ -306,10 +304,8 @@ vmw_ioctl_region_create(struct vmw_winsys_screen *vws,
uint32_t size)
memset(&arg, 0, sizeof(arg));
req->size = size;
- do {
- ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_ALLOC_DMABUF, &arg,
+ ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_ALLOC_DMABUF, &arg,
sizeof(arg));
- } while (ret == -ERESTART);
if (ret) {
debug_printf("IOCTL failed %d: %s\n", ret, strerror(-ret));
@@ -436,10 +432,8 @@ vmw_ioctl_sync(struct vmw_winsys_screen *vws,
memset(&arg, 0, sizeof(arg));
arg.sequence = fence;
- do {
- ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_FENCE_WAIT, &arg,
+ ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_FENCE_WAIT, &arg,
sizeof(arg));
- } while (ret == -ERESTART);
}
--
1.6.4
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Fwd: RFC: libdrm repo
On Sun, 2009-11-22 at 10:04 -0600, Dee Sharpe wrote: > I meant to send this to the mailing list, instead of an individual > person! > > Dee Sharpe > > > Sent from my iPhone > > Begin forwarded message: > > > > From: Dee Sharpe > > Date: November 22, 2009 9:44:22 AM CST > > To: Robert Noland > > Subject: Re: RFC: libdrm repo > > > > > > > So, none of the *BSD code will ever be used??? Does it even work or > > compile??? I hope so, since I've been using the *BSD code as a basis > > for a Syllable port. I find the *BSD code a bit easier to read. Have > > I been wasting my time??? No, probably not... But the code that is/was there is outdated since trying to track a seperate private repo for each hardware platform is more than difficult enough. Certain vendors decided that it was too much trouble to maintain their code and expected those that still wanted a multi-os multi-vendor repo to backport their code for them. This eventually forced all of the vendors to move to private repos. The place to see the current FreeBSD code is http://svn.freebsd.org/viewvc/base/head/sys/dev/drm/ robert. > > Dee Sharpe > > > > Sent from my iPhone > > > > On Nov 22, 2009, at 8:31 AM, Robert Noland wrote: > > > > > On Sun, 2009-11-22 at 19:01 +1000, Dave Airlie wrote: > > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens > > > > wrote: > > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: > > > > > > > I see that you deleted bsd-core dispite the requests of a > > > > > > > number of > > > > > > > people that you do not. > > > > > > > > > > > > Its git, nobody has touched any of it in ages, and none of > > > > > > the BSD > > > > > > maintainers used it, you can just get it back by branching > > > > > > from the commit > > > > > > before its removal, if you think revival is needed, don't > > > > > > bring back > > > > > > linux-core when you do please. > > > > > > > > > > I already told the both of you that I was planning to use it > > > > > on IRC, I just > > > > > haven't had time to put anything in. > > > > > > > > > > In addition, he's asking for a repro to libdrm. The way I see > > > > > it, is there > > > > > were two choices: > > > > > 1) repro to libdrm, add the changes, not piss people off > > > > > 2) add the changes, repro to libdrm, piss people off > > > > > > > > I think we pissed one person off, not people, as I said, there > > > > are two > > > > people registered as BSD maintainers for drm code, oga and > > > > rnoland, > > > > neither of them cared. I'm not sure what value the codebase has > > > > if > > > > neither Free or OpenBSD are going to use it. > > > > > > > > Why bother adding code to a common tree that no operating system > > > > has any intention of shipping ever. > > > > > > Well, I think that it is safe to say that I really don't like > > > things as > > > they are. Under the circumstances however, the code there is > > > useless and > > > only provided minor historical value. > > > > > > robert. > > > > > > > Dave. > > > > > > > > -- > > > > Let Crystal Reports handle the reporting - Free Crystal Reports > > > > 2008 30-Day > > > > trial. Simplify your report design, integration and deployment - > > > > and focus on > > > > what you do best, core application coding. Discover what's new > > > > with > > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > > -- > > > > ___ > > > > Dri-devel mailing list > > > > dri-de...@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > -- > > > Robert Noland > > > 2Hip Networks > > > > > > > > > -- > > > Let Crystal Reports handle the reporting - Free Crystal Reports > > > 2008 30-Day > > > trial. Simplify your report design, integration and deployme
Re: [Mesa3d-dev] [RFC] Proposed Mesa 7.7 / 7.6.1 release schedule
On Wed, 2009-11-18 at 07:44 -0700, Brian Paul wrote: > Ian Romanick wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > As promised, I'm sending out a proposed release schedule before the 11th > > hour. Doing a simultaneous x.y.z and x.y+1 release worked out pretty > > well last time, so I propose to do the same thing again. The RC and > > final dates below are for both 7.7 and 7.6.1. > > > > The RC1 date is pretty important as it aligns with at least one distro's > > release schedule. > > > > Create mesa_7_7_branch11/19 > > RC1 11/30 > > RC2 12/7 > > RC3 12/14 > > final 12/21 > > > > The goal is for RC3 and final to be the identical with the exception of > > version strings and repository tags. > > It looks like mesa_7_7_branch has been created a day ahead of > schedule. That's OK. > > I'd like to propose fast-tracking the 7.6.1 release to minimize the > time during which we have to worry about having 3 active branches > (mesa_7_6_branch, mesa_7_7_branch and master). > > The 7.6.1 release should be ready to go at any time since it's just > bug fixes. So I'd like to make a release candidate today, and release > 7.6.1 by the end of the week. > > Any objections? I've been waiting on 7.6.1 to ship in FreeBSD, so I'm all for it. robert. > -Brian > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Robert Noland 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Importing "real" strtod code
On Fri, 2009-10-09 at 13:06 +0100, José Fonseca wrote: > On Fri, 2009-10-09 at 03:32 -0700, Chris Rankin wrote: > > --- On Fri, 9/10/09, Robert Noland wrote: > > > You can't include GPL code into an MIT project without > > > poluting the license. > > > > Ah. So that means Mesa would need the GLIBC copyright holder's explicit > > permission ... That would be Uli Drepper, presumably. > > > > Cheers, > > Chris > > AFAIK all FSF sanctioned projects are copyright FSF. It's one of the > condition to submit patches to those projects that you have to sign and > mail a statement assigning copyright to FSF, so that they can legally > defend the project and other stuff. > > There's also http://sourceware.org/newlib/ which appears to be a BSD > like license. For that matter, there is always the version from FreeBSD, which is of course BSD licensed. robert. > Jose > -- Robert Noland 2Hip Networks -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Importing "real" strtod code
On Fri, 2009-10-09 at 01:03 -0700, Chris Rankin wrote: > --- On Thu, 8/10/09, Brian Paul wrote: > > I think that we could just bracket the call to > > _slang_compile() with the set/restore-locale calls. > > I'd hate to make an obvious suggestion, but... can't you just copy strtod() > code (without the locale support) from GLIBC? My basic research suggests that > the MIT license is compatible with the GPL... > > Core Mesa *is* licensed under the MIT license, isn't it? You can include MIT code in a GPL project without impact to the license. You can't include GPL code into an MIT project without poluting the license. robert. > Cheers, > Chris > > > > > -- > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Robert Noland 2Hip Networks -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] util: Enable sockets on BSD
I think this should be safe for all of the BSDs.
Signed-off-by: Robert Noland
---
src/gallium/auxiliary/util/u_network.c |6 +++---
src/gallium/auxiliary/util/u_network.h |2 +-
src/gallium/drivers/trace/tr_rbug.c|2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_network.c
b/src/gallium/auxiliary/util/u_network.c
index bc4b758..6269c72 100644
--- a/src/gallium/auxiliary/util/u_network.c
+++ b/src/gallium/auxiliary/util/u_network.c
@@ -6,7 +6,7 @@
#if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
# include
# include
-#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU)
+#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_BSD)
# include
# include
# include
@@ -54,7 +54,7 @@ u_socket_close(int s)
if (s < 0)
return;
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_BSD)
shutdown(s, SHUT_RDWR);
close(s);
#elif defined(PIPE_SUBSYSTEM_WINDOWS_USER)
@@ -169,7 +169,7 @@ u_socket_listen_on_port(uint16_t portnum)
void
u_socket_block(int s, boolean block)
{
-#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU)
+#if defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_BSD)
int old = fcntl(s, F_GETFL, 0);
if (old == -1)
return;
diff --git a/src/gallium/auxiliary/util/u_network.h
b/src/gallium/auxiliary/util/u_network.h
index 8c778f4..0aa898b 100644
--- a/src/gallium/auxiliary/util/u_network.h
+++ b/src/gallium/auxiliary/util/u_network.h
@@ -6,7 +6,7 @@
#if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
# define PIPE_HAVE_SOCKETS
-#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU)
+#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_HAIKU) || defined(PIPE_OS_BSD)
# define PIPE_HAVE_SOCKETS
#endif
diff --git a/src/gallium/drivers/trace/tr_rbug.c
b/src/gallium/drivers/trace/tr_rbug.c
index e85ac15..81e0a6f 100644
--- a/src/gallium/drivers/trace/tr_rbug.c
+++ b/src/gallium/drivers/trace/tr_rbug.c
@@ -44,7 +44,7 @@
#if defined(PIPE_SUBSYSTEM_WINDOWS_USER)
# define sleep Sleep
-#elif defined(PIPE_OS_LINUX)
+#elif defined(PIPE_OS_LINUX) || defined(PIPE_OS_BSD)
void usleep(int);
# define sleep usleep
#else
--
1.6.4
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] util: define PIPE_OS_FREEBSD to correct u_cpu_detect on FreeBSD.
Since the various BSDs use some different features here, define PIPE_OS_OPENBSD and PIPE_OS_NETBSD as well Signed-off-by: Robert Noland --- src/gallium/include/pipe/p_config.h | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h index 78fe1f4..f6feea5 100644 --- a/src/gallium/include/pipe/p_config.h +++ b/src/gallium/include/pipe/p_config.h @@ -126,6 +126,19 @@ #endif #if defined(__FreeBSD__) +#define PIPE_OS_FREEBSD +#define PIPE_OS_BSD +#define PIPE_OS_UNIX +#endif + +#if defined(__OpenBSD__) +#define PIPE_OS_OPENBSD +#define PIPE_OS_BSD +#define PIPE_OS_UNIX +#endif + +#if defined(__NetBSD__) +#define PIPE_OS_NETBSD #define PIPE_OS_BSD #define PIPE_OS_UNIX #endif -- 1.6.4 -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Allow not building any drivers
I was asked to commit this patch, but I wanted to check first. Does this look ok? thanks, robert. 0001-autoconf-disable-dri-drivers-build-if-being-asked.patch Description: application/mbox signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
