[Dri-devel] radeon, frame buffer -> texture copy
copyTexImage2D et al. seem horribly slow for anything more than few hundred pixels. It seems from radeon_tex.c that frame buffer -> texture operations are implemented without any hardware help from the card: ctx->Driver.CopyTexImage1D = _swrast_copy_teximage1d; ctx->Driver.CopyTexImage2D = _swrast_copy_teximage2d; Is this due to some fundamental limitation of radeon cards? (mine is a 7500) How could this be done with hardware support? Could this be done with same onboard machinery that puts texels to frame buffer, only in reverse? How difficult would this be to implement? -- Peter Lamberg <[EMAIL PROTECTED]> --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 757] Cut and paste error in radeon_probe.c
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=757
--- Additional Comments From [EMAIL PROTECTED] 2003-03-10 06:45 ---
In the same file, another inconsistency is present:
{ PCI_CHIP_R350_NK, "ATI FireGL (R350) NL (AGP)" },
should be:
{ PCI_CHIP_R350_NK, "ATI FireGL (R350) NK (AGP)" },
There are also many chips for which the PCI ID is present int xf86PciInfo.h
but not present in the driver itself. I can make a patch that fixes
all of these problems in a few weeks if nobody gets to it, as I'm planning
on adding support for newer ATI chips anyway, and would like to get that
merged then.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] when I had the choice ....
On Thu, 2003-10-02 at 13:46, Sven Luther wrote: > On Thu, Oct 02, 2003 at 10:12:21AM +0200, Thomas Emmel wrote: > > > > we are currently looking for the best graphics cards for linux and > > OpenGL. Can someone give me a hint which of the currently available > > cards are the best to use for extensive 3D applications in technical > > field (CAD, visualization of finite element data etc., no games). > > Well, the best supported card with free driver would be any with the > radeon R200 core (8500, 9000, 9100 and 9200). The caveat being that the r200 driver still has some problems with hardware TCL, which might affect complex visualisation apps. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon, frame buffer -> texture copy
Peter Lamberg wrote: copyTexImage2D et al. seem horribly slow for anything more than few hundred pixels. It seems from radeon_tex.c that frame buffer -> texture operations are implemented without any hardware help from the card: ctx->Driver.CopyTexImage1D= _swrast_copy_teximage1d; ctx->Driver.CopyTexImage2D= _swrast_copy_teximage2d; Is this due to some fundamental limitation of radeon cards? (mine is a 7500) How could this be done with hardware support? Could this be done with same onboard machinery that puts texels to frame buffer, only in reverse? How difficult would this be to implement? The real issue here is memory management of the texture space. Because there is currently no mechanism to 'pin' on-card or agp texture memory, that memory can be stolen & overwritten by other contexts at potentially any time. The driver copes with this by always keeping a copy of textures in main memory. This works fine most of the time. Unfortunately, it means that when you do a CopyTexSubImage or whatever, it is necessary to suck the data out of the card to get that copy in main memory. Ian started work on a better memory manager, and I have a makeshift one on the i865 branch. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Merging radeon mergedfb patch before 4.4.0
With my latest patch the just about all the outstanding bugs have been fixed. the only thing remaining is that pagflipping doesn't always work in some mergedfb configurations. I'm working on that one, but then again, pageflipping doesn't work for everyone anyway. The driver currently supports all major features you'd want in a dualheaded setup: 3D on both heads, Xv overlay moves from one crtc to the other depending on where the output is, and it provides a pseudo-xinerama extension for window placement and such. What are your thoughts on merging the radeon mergedfb patch into CVS? I agree that it would probably be a better idea to separate out the device independant code, but I'm not sure I'll have time to do that and test it before the 4.4 feature freeze (oct 15th). Also merging the driver now, as is, doesn't mean it can't be converted to the device independant code later on. I've emailed Kevin E. Martin as well to get his thoughts. Will there be another xfree86<->DRI merge before the release? will Felix' config code make it in? Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] firstLevel / lastLevel calculation in R200 driver
Ian Romanick wrote: A long time ago I promided to refactor the firstLevel / lastLevel calculation code from the various *SetTexImages routines. I have a patch that does this, and it follows the definition of how firstLevel & lastLevel selection should work pretty closely. The only problem is that this does NOT grok with the way the R200 driver calculates it for GL_TEXTURE_3D. 3D textures are supposed to work just like 1D, 2D, and cubemap textures. However, the R200 driver picks baseLevel for firstLevel and lastLevel. Does this represent some limitation of the r200 hardware or was it just an oversight? I know that 3D textures are not currently hardware accelerated, but they will be someday. I don't want to put code in that will "break" when that happens. Actually, I added support for HW 3D textures (and cube maps) last winter (or so). The r200 doesn't support mipmapped 3D textures, so that would have to be a fallback path, but non-mipmapped 3D textures are hardware accelerated. The one bit missing was support for glTexCoord3 in the vertex buffers. That's Keith's area of expertise. 3D texgen works though. -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merging radeon mergedfb patch before 4.4.0
On Fri, 3 Oct 2003 07:31:49 -0700 (PDT) Alex Deucher <[EMAIL PROTECTED]> wrote: > With my latest patch the just about all the outstanding bugs have been > fixed. the only thing remaining is that pagflipping doesn't always > work in some mergedfb configurations. I'm working on that one, but > then again, pageflipping doesn't work for everyone anyway. The driver > currently supports all major features you'd want in a dualheaded setup: > 3D on both heads, Xv overlay moves from one crtc to the other depending > on where the output is, and it provides a pseudo-xinerama extension for > window placement and such. > What are your thoughts on merging the radeon mergedfb patch into CVS? > I agree that it would probably be a better idea to separate out the > device independant code, but I'm not sure I'll have time to do that and > test it before the 4.4 feature freeze (oct 15th). Also merging the > driver now, as is, doesn't mean it can't be converted to the device > independant code later on. I've emailed Kevin E. Martin as well to get > his thoughts. Will there be another xfree86<->DRI merge before the > release? will Felix' config code make it in? I hope there will be another merge from xfree86 soon. The current version still has a segfault in xdmcp code if there is no IPv6 in the kernel that was fixed recently. I'm going merge the config branch to the DRI CVS trunk this weekend. > > Thanks, > > Alex Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: fixing pageflipping in mergedfb modes
On Thu, 2003-10-02 at 18:41, Alex Deucher wrote: > I'm attempting to fix pageflipping in certain mergedfb modes. right > now it only works in when crtc2 is right of crtc1. I suspect the > problem has to do with the CRTC offsets that are set in > RADEONDoAdjustFrame() > > for instance if I have crtc2 left of or above crtc1, I would need to > adjust RADEON_CRTC_OFFSET by something like (crtc2_mode->CrtcHDisplay * > crtc2_mode->CrtcVDisplay) right? and for clone mode, I'd have to > adjust the offsets depending on the modes of each head. is my thinking > right here? or does it work differently? I wouldn't think anything like this should be necessary as long as the values passed to RADEONDoAdjustFrame() are virtual screen coordinates, but you may have become more competent than me in this area. :) > Also, looking at radeon_dri.c, RADEONDRIFinishScreenInit() could we cap > the 3D engine to 2048x2048 my adjusting the values of pRADEONDRI->width > and pRADEONDRI->height? something like: > > if (pScrn->virtualX > 2048) > pRADEONDRI->width = 2048; > else > pRADEONDRI->width = pScrn->virtualX; > if (pScrn->virtualY > 2048) > pRADEONDRI->width = 2048; > else > pRADEONDRI->width = pScrn->virtualY; I doubt this would have a useful effect, if any (do the Radeon 3D drivers even use these fields?). As I have hinted repeatedly before, the only sane way to handle this for now is probably to disable the DRI if either virtual dimension exceeds 2048. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merging radeon mergedfb patch before 4.4.0
On Fri, 2003-10-03 at 16:31, Alex Deucher wrote: > > What are your thoughts on merging the radeon mergedfb patch into CVS? > I agree that it would probably be a better idea to separate out the > device independant code, but I'm not sure I'll have time to do that and > test it before the 4.4 feature freeze (oct 15th). Also merging the > driver now, as is, doesn't mean it can't be converted to the device > independant code later on. I agree, but this is Kevin's call. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Merging radeon mergedfb patch before 4.4.0
On Fri, Oct 03, 2003 at 07:31:49AM -0700, Alex Deucher wrote: >his thoughts. Will there be another xfree86<->DRI merge before the >release? will Felix' config code make it in? There won't be any further wholesale DRI->XFree86 merge. Instead, new features and bug fixes should be separated out and submitted to XFree86 for consideration for the upcoming release before the deadline(s). New stuff should be discussed in advance on the broader XFree86 development list so that there are no surprises, and it'd be helpful all around if you guys maintained some sort of changelog. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: fixing pageflipping in mergedfb modes
--- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Thu, 2003-10-02 at 18:41, Alex Deucher wrote: > > I'm attempting to fix pageflipping in certain mergedfb modes. > right > > now it only works in when crtc2 is right of crtc1. I suspect the > > problem has to do with the CRTC offsets that are set in > > RADEONDoAdjustFrame() > > > > for instance if I have crtc2 left of or above crtc1, I would need > to > > adjust RADEON_CRTC_OFFSET by something like > (crtc2_mode->CrtcHDisplay * > > crtc2_mode->CrtcVDisplay) right? and for clone mode, I'd have to > > adjust the offsets depending on the modes of each head. is my > thinking > > right here? or does it work differently? > > I wouldn't think anything like this should be necessary as long as > the > values passed to RADEONDoAdjustFrame() are virtual screen > coordinates, > but you may have become more competent than me in this area. :) > I would have thought the same thing as well, but Xv required that I take into account the width of crtc2 when using the overlay on crtc1 in "leftof" mode. I'm seeing similar behavior when using pageflipping (the framebuffer is offset on crtc1) in "leftof" mode so that may require a similar fix. I'll report back when I mess with it a bit more. > > > Also, looking at radeon_dri.c, RADEONDRIFinishScreenInit() could we > cap > > the 3D engine to 2048x2048 my adjusting the values of > pRADEONDRI->width > > and pRADEONDRI->height? something like: > > > > if (pScrn->virtualX > 2048) > > pRADEONDRI->width = 2048; > > else > > pRADEONDRI->width = pScrn->virtualX; > > if (pScrn->virtualY > 2048) > > pRADEONDRI->width = 2048; > > else > > pRADEONDRI->width = pScrn->virtualY; > > I doubt this would have a useful effect, if any (do the Radeon 3D > drivers even use these fields?). As I have hinted repeatedly before, > the > only sane way to handle this for now is probably to disable the DRI > if > either virtual dimension exceeds 2048. > Yeah, that's what I figured, I say the code and thought I would ask. I'll dif further this weekend. thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI Radeon Screen Coruption
I have a screenshot of screen coruption occuring with the radeon driver. This Screenshot is >500k with compression so if you are interested, please email me so I can forward it on (so I don't waste list bandwidth). I have a Radeon 9000 PCI. This coruption does not occur in windows with DirectX 9.0b. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] merging to branches
Okay, I was going to merge trunk to the savage-1_0_0-branch, since updates to the savage driver in trunk help out with that work I've been told. I went to the CvsPolicy wiki page and based on that did a tag on the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update -d -j HEAD. It ran for a while, and produced a large number of conflicts. Why should there be conflicts in files that weren't touched by the savage-branch? Is there a way to avoid having to deal with all of those? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
FWIW, the 2D drivers from the trunk and the code drop from VIA are VERY different. I'm not sure where you are seeing the conflicts... just an FYI... --- Eric Anholt <[EMAIL PROTECTED]> wrote: > Okay, I was going to merge trunk to the savage-1_0_0-branch, since > updates to the savage driver in trunk help out with that work I've > been > told. I went to the CvsPolicy wiki page and based on that did a tag > on > the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs > update > -d -j HEAD. It ran for a while, and produced a large number of > conflicts. Why should there be conflicts in files that weren't > touched > by the savage-branch? Is there a way to avoid having to deal with > all > of those? > > -- > Eric Anholt[EMAIL PROTECTED] > http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
On Fri, 03 Oct 2003 12:14:32 -0700 Eric Anholt <[EMAIL PROTECTED]> wrote: > Okay, I was going to merge trunk to the savage-1_0_0-branch, since > updates to the savage driver in trunk help out with that work I've been Are you referring to the patch that Rafael Máximo sent yesterday? I was going to look at it, but I didn't have time yet. After a quick glance it looks like it reverts lots of changes S3 made to the driver. > told. I went to the CvsPolicy wiki page and based on that did a tag on > the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update > -d -j HEAD. It ran for a while, and produced a large number of > conflicts. Why should there be conflicts in files that weren't touched > by the savage-branch? Is there a way to avoid having to deal with all > of those? This is probably related to keyword substitutions. There is a node "Merging and keywords" in the CVS info documentation. Basically you should add "-kk" to the cvs update command line. This way keywords are not substituded and can't cause phantom conflicts. > > -- > Eric Anholt[EMAIL PROTECTED] > http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
On Fri, 2003-10-03 at 13:55, Felix Kühling wrote: > On Fri, 03 Oct 2003 12:14:32 -0700 > Eric Anholt <[EMAIL PROTECTED]> wrote: > > > Okay, I was going to merge trunk to the savage-1_0_0-branch, since > > updates to the savage driver in trunk help out with that work I've been > > Are you referring to the patch that Rafael Máximo sent yesterday? I was > going to look at it, but I didn't have time yet. After a quick glance it > looks like it reverts lots of changes S3 made to the driver. That patch was based quite a bit on updates in XFree86 CVS from what I saw. I hadn't really looked at the 4.3.0 -> S3 changes to compare how much the trunk merge changes would affect that code. But then, if it fixes basic 2d rendering problems, maybe we shouldn't worry too much about how it messes with the S3 changes for now. It would be good to have someone with hardware who could test the 4.2.0 libGL/savage_dri.so against the CVS DDX before and after a trunk merge to see if it breaks things. Unfortunately, from what I've been told now the savage card I have (an MX) won't work. > > told. I went to the CvsPolicy wiki page and based on that did a tag on > > the savage branch of savage-1_0_0-trunk-premerge. Then I did cvs update > > -d -j HEAD. It ran for a while, and produced a large number of > > conflicts. Why should there be conflicts in files that weren't touched > > by the savage-branch? Is there a way to avoid having to deal with all > > of those? > > This is probably related to keyword substitutions. There is a node > "Merging and keywords" in the CVS info documentation. Basically you > should add "-kk" to the cvs update command line. This way keywords are > not substituded and can't cause phantom conflicts. Ahh, I'll give that a try. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
On Fri, 03 Oct 2003 14:28:50 -0700 Eric Anholt <[EMAIL PROTECTED]> wrote: > On Fri, 2003-10-03 at 13:55, Felix Kühling wrote: > > On Fri, 03 Oct 2003 12:14:32 -0700 > > Eric Anholt <[EMAIL PROTECTED]> wrote: > > > > > Okay, I was going to merge trunk to the savage-1_0_0-branch, since > > > updates to the savage driver in trunk help out with that work I've been > > > > Are you referring to the patch that Rafael Máximo sent yesterday? I was > > going to look at it, but I didn't have time yet. After a quick glance it > > looks like it reverts lots of changes S3 made to the driver. > > That patch was based quite a bit on updates in XFree86 CVS from what I > saw. I hadn't really looked at the 4.3.0 -> S3 changes to compare how > much the trunk merge changes would affect that code. But then, if it > fixes basic 2d rendering problems, maybe we shouldn't worry too much > about how it messes with the S3 changes for now. I agree. The only important changes are the ones that make the DDX driver DRI aware. We'll have to be careful not to mess up hardware locking. > > It would be good to have someone with hardware who could test the 4.2.0 > libGL/savage_dri.so against the CVS DDX before and after a trunk merge > to see if it breaks things. Unfortunately, from what I've been told now > the savage card I have (an MX) won't work. I'll see if I can set up something like that. I would have to try and run an Xserver and savage DDX driver from the savage-1_0_0-branch with an old libGL and savage_dri.so. I would need to get Xfree86 4.2 sources and the original S3 code in order to compile a working 3D driver, right. That won't happen before some time next week. > [snip] > -- > Eric Anholt[EMAIL PROTECTED] > http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] > __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] merging to branches
>> It would be good to have someone with hardware who could test the 4.2.0 >> libGL/savage_dri.so against the CVS DDX before and after a trunk merge >> to see if it breaks things. Unfortunately, from what I've been told now >> the savage card I have (an MX) won't work. > > I'll see if I can set up something like that. I would have to try and > run an Xserver and savage DDX driver from the savage-1_0_0-branch with > an old libGL and savage_dri.so. I would need to get Xfree86 4.2 sources > and the original S3 code in order to compile a working 3D driver, right. > That won't happen before some time next week. > I have 4.2 sources and will try Rafael's patch with the savage branch, please explain me what test do you want done and I'll try to do it. I couldn't get the 4.2.0 dri drivers to work because my apps are linked against a newer libGL --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Snapshot script changes for xdriinfo
Hi, I made some modifications to the snapshot scripts in order to include xdriinfo and its manpage in the snapshots of the config-0-0-1-branch or the trunk after the merge. A patch is attached. I chose to use the extras subdirectory with its own install script. The disadvantage is that this does not allow restoring of backup files on deinstallation. But this is no problem as these files don't exist XFree86 releases. The advantage is that I didn't have to touch the install script. I tested the modifications by building snapshots for the trunk and the branch with the changed scripts. They looked all right, though I didn't try a full installation. I only tested the generated extras.sh script. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- package.sh~ 2003-10-02 13:54:43.0 +0200 +++ package.sh 2003-10-04 01:29:09.0 +0200 @@ -12,6 +12,7 @@ case $BRANCH in config-*-*-*-branch) DRIVERS="MGA R128 R200 RADEON" + EXTRAS="XDRIINFO" ;; mach64-*-*-*-branch) DRIVERS="MACH64" @@ -29,7 +30,7 @@ for DRIVER in $DRIVERS do - ./dripkg.sh $BUILD cvs/$BRANCH build/$BRANCH $DRIVER || EXIT=1 + ./dripkg.sh $BUILD cvs/$BRANCH build/$BRANCH $DRIVER "$EXTRAS" || EXIT=1 done rm -rf dripkg --- dripkg.sh~ 2003-10-02 13:54:32.0 +0200 +++ dripkg.sh 2003-10-04 01:22:31.0 +0200 @@ -10,9 +10,10 @@ # Usage: # -# dripkg.sh +# dripkg.sh # # is one of the following... R128, RADEON, MGA, TDFX, I810 +# is a list of extras... XDRIINFO set -e @@ -23,6 +24,7 @@ DRV_CVS_DIR=$2 DRV_BLD_DIR=$3 DRV=$4 +EXTRAS="$5" # CVS Variables DDX_SUBDIR=xc/programs/Xserver/hw/xfree86/drivers @@ -31,6 +33,7 @@ DRI_SUBDIR=xc/lib/GL/mesa/src/drv LIB_SUBDIR=xc/lib CORE_SUBDIR=xc/programs/Xserver +XDRIINFO_SUBDIR=xc/programs/xdriinfo # Package Variables PKG_DIR="dripkg" @@ -170,6 +173,7 @@ DRV_DRI_DIR=$DRV_BLD_DIR/$DRI_SUBDIR/$DRV_DRI_SUBDIR DRV_LIB_DIR=$DRV_BLD_DIR/$LIB_SUBDIR DRV_CORE_DIR=$DRV_BLD_DIR/$CORE_SUBDIR +XDRIINFO_DIR=$DRV_BLD_DIR/$XDRIINFO_SUBDIR # Get package name if [ -n "$DRV_BUILD_TAG" ] @@ -248,6 +252,44 @@ cp $DRV_CORE_DIR/hw/xfree86/os-support/linux/drm/libdrm.a $PKG_CORE_DIR strip -g $PKG_CORE_DIR/libdrm.a +# Copy extras and write extras.sh +if [ -n "$EXTRAS" ] +then +vecho -n "Copying extras and writing extras.sh..." +mkdir -p $PKG_DIR/extras +cat > $PKG_DIR/extras/extras.sh <> $PKG_DIR/extras/extras.sh <&2 + ;; + esac +done +if [ -n "$EXTRAS" ] +then +vecho "" +fi + # Execute Driver Specific Commands vecho "Running driver specific commands..." `$DRV_COMMAND`
