Re: [Dri-devel] Switching dri over to new drm tree
anything after that did not have working direct rendering. But since the snaps are generated from the head... I've seen this error posted here before but I haven't seen a resolution, maybe I missed it. Ian, does this look at all like it could be related to your libGL, etc. changes? yup if I just build HEAD and install it it works fine.. so it looks like a snapshot + older libGL issue.. I'm not really setup for testing that sorta thing here... I've always been a build HEAD and install :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
ajax wrote: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 144 (XFree86-DRI) Minor opcode of failed request: 5 () Value in failed request: 0x1e2 Serial number of failed request: 30 Current serial number in output stream: 30 This was installed from a snapshot. Snapshots up to March 2 worked, anything after that did not have working direct rendering. But since the snaps are generated from the head... I've seen this error posted here before but I haven't seen a resolution, maybe I missed it. As far as I know, that was fixed on 3/13. I tested my fix with two different drivers (one that uses the new interface and one that doesn't) from both the DRI tree and XFree86 (post 4.4.0) CVS. I don't have time to deal with it now. Sorry. http://marc.theaimsgroup.com/?l=dri-develm=107914598527974w=2 --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
ajax wrote: ... The i810 error is not a build failure but a runtime failure with glxgears: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 144 (XFree86-DRI) Minor opcode of failed request: 5 () Value in failed request: 0x1e2 Serial number of failed request: 30 Current serial number in output stream: 30 This was installed from a snapshot. Snapshots up to March 2 worked, anything after that did not have working direct rendering. But since the snaps are generated from the head... I've seen this error posted here before but I haven't seen a resolution, maybe I missed it. Ian, does this look at all like it could be related to your libGL, etc. changes? Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
This was installed from a snapshot. Snapshots up to March 2 worked, anything after that did not have working direct rendering. But since the snaps are generated from the head... I've seen this error posted here before but I haven't seen a resolution, maybe I missed it. Ian, does this look at all like it could be related to your libGL, etc. changes? I'll try and test this tomorrow at work.. have been off doing some non graphics works... Dave. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wednesday 17 March 2004 14:06, ajax wrote: No problem. I split the branches into current, sleeping, merged, and obsolete, and added a note about the DRM changes. I'll be adding more to that list shortly. Added a few to the list, mostly things I've had trouble with while getting tdfx to work again. In the future, if a change to the trunk requires changes in a current or sleeping branch, it should get a link on that list. Of course ideally we'd have no sleeping branches... Which reminds me. Brian, you'd said in: http://marc.theaimsgroup.com/?l=dri-develm=107099482602285w=2 that DRI builds should happen against a tagged Mesa branch. Currently the Building page tells people to build against HEAD. I know that's not good, but is that branch still the officially-blessed branch for stable builds? - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
ajax wrote: On Wednesday 17 March 2004 14:06, ajax wrote: No problem. I split the branches into current, sleeping, merged, and obsolete, and added a note about the DRM changes. I'll be adding more to that list shortly. Added a few to the list, mostly things I've had trouble with while getting tdfx to work again. In the future, if a change to the trunk requires changes in a current or sleeping branch, it should get a link on that list. Of course ideally we'd have no sleeping branches... Which reminds me. Brian, you'd said in: http://marc.theaimsgroup.com/?l=dri-develm=107099482602285w=2 that DRI builds should happen against a tagged Mesa branch. Currently the Building page tells people to build against HEAD. I know that's not good, but is that branch still the officially-blessed branch for stable builds? For the meantime, yes. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
ajax wrote: On Wednesday 17 March 2004 14:06, ajax wrote: No problem. I split the branches into current, sleeping, merged, and obsolete, and added a note about the DRM changes. I'll be adding more to that list shortly. Added a few to the list, mostly things I've had trouble with while getting tdfx to work again. In the future, if a change to the trunk requires changes in a current or sleeping branch, it should get a link on that list. Of course ideally we'd have no sleeping branches... Which reminds me. Brian, you'd said in: http://marc.theaimsgroup.com/?l=dri-develm=107099482602285w=2 that DRI builds should happen against a tagged Mesa branch. Currently the Building page tells people to build against HEAD. I know that's not good, but is that branch still the officially-blessed branch for stable builds? I figured people doing driver development would prefer to work on a stable Mesa branch, but it hasn't panned out that way. I guess I don't feel too strongly either way. I don't think anyone's checked in any DRI driver changes to the stable mesa_6_0_branch branch so I'm not sure what state it's in. -Brian --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Friday 19 March 2004 12:26, Brian Paul wrote: I figured people doing driver development would prefer to work on a stable Mesa branch, but it hasn't panned out that way. I guess I don't feel too strongly either way. I don't think anyone's checked in any DRI driver changes to the stable mesa_6_0_branch branch so I'm not sure what state it's in. -Brian Well right now HEAD doesn't work for at least i810 and probably some others. I'm not so much concerned for the developers as for the users who just want to download it and have it work. Telling them to build against the stable branch (like (edit edit edit) the docs now say) should help. I hope. I suppose the next user to wander into #dri and ask me, gets to be the guinea pig. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
Jon Smirl wrote: This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree You will also need to fix MesaSrcDir make World dri branches will also need to apply this patch Checkout still fails: [EMAIL PROTECTED] xc-trunk]$ cvs checkout drm cvs checkout: Updating drm cvs checkout: Updating drm/bsd U drm/bsd/Imakefile U drm/bsd/Makefile.bsd U drm/bsd/ati_pcigart.h U drm/bsd/drmP.h U drm/bsd/drm_agpsupport.h U drm/bsd/drm_auth.h U drm/bsd/drm_bufs.h U drm/bsd/drm_context.h U drm/bsd/drm_dma.h U drm/bsd/drm_drawable.h U drm/bsd/drm_drv.h U drm/bsd/drm_fops.h U drm/bsd/drm_ioctl.h U drm/bsd/drm_irq.h U drm/bsd/drm_lock.h U drm/bsd/drm_memory.h U drm/bsd/drm_memory_debug.h U drm/bsd/drm_os_freebsd.h U drm/bsd/drm_os_netbsd.h U drm/bsd/drm_pci.h U drm/bsd/drm_scatter.h U drm/bsd/drm_sysctl.h U drm/bsd/drm_vm.h U drm/bsd/mga_drv.c U drm/bsd/r128_drv.c U drm/bsd/radeon_drv.c U drm/bsd/sis_drv.c U drm/bsd/tdfx_drv.c cvs checkout: Updating drm/bsd/drm cvs checkout: failed to create lock directory for `/cvs/dri/drm/bsd/drm' (/cvs/dri/drm/bsd/drm/#cvs.lock): Permission denied cvs checkout: failed to obtain dir lock in repository `/cvs/dri/drm/bsd/drm' cvs [checkout aborted]: read lock failed - giving up I tried to patch up the bsd build but I don't run bsd so could someone please check it. Give me feedback and I can adjust the drm directory structure or the patch. When everyone likes the new setup I will commit the patch. It will only take a minute to do the switch over, I'll recopy the drm CVS v files when switching to pick up any new checkins. After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working We want to make sure it is still relatively easy for XFree86 to pull in new versions of the DRM. If we're making a shellscript to translate our files into the kernel's structure, maybe one to do the same job for XFree86 is sensible. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wed, Mar 17, 2004 at 09:14:52AM +, Keith Whitwell wrote: Jon Smirl wrote: This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree You will also need to fix MesaSrcDir make World dri branches will also need to apply this patch Checkout still fails: [EMAIL PROTECTED] xc-trunk]$ cvs checkout drm cvs checkout: Updating drm cvs checkout: Updating drm/bsd U drm/bsd/Imakefile U drm/bsd/Makefile.bsd U drm/bsd/ati_pcigart.h U drm/bsd/drmP.h U drm/bsd/drm_agpsupport.h U drm/bsd/drm_auth.h U drm/bsd/drm_bufs.h U drm/bsd/drm_context.h U drm/bsd/drm_dma.h U drm/bsd/drm_drawable.h U drm/bsd/drm_drv.h U drm/bsd/drm_fops.h U drm/bsd/drm_ioctl.h U drm/bsd/drm_irq.h U drm/bsd/drm_lock.h U drm/bsd/drm_memory.h U drm/bsd/drm_memory_debug.h U drm/bsd/drm_os_freebsd.h U drm/bsd/drm_os_netbsd.h U drm/bsd/drm_pci.h U drm/bsd/drm_scatter.h U drm/bsd/drm_sysctl.h U drm/bsd/drm_vm.h U drm/bsd/mga_drv.c U drm/bsd/r128_drv.c U drm/bsd/radeon_drv.c U drm/bsd/sis_drv.c U drm/bsd/tdfx_drv.c cvs checkout: Updating drm/bsd/drm cvs checkout: failed to create lock directory for `/cvs/dri/drm/bsd/drm' (/cvs/dri/drm/bsd/drm/#cvs.lock): Permission denied cvs checkout: failed to obtain dir lock in repository `/cvs/dri/drm/bsd/drm' cvs [checkout aborted]: read lock failed - giving up I tried to patch up the bsd build but I don't run bsd so could someone please check it. Give me feedback and I can adjust the drm directory structure or the patch. When everyone likes the new setup I will commit the patch. It will only take a minute to do the switch over, I'll recopy the drm CVS v files when switching to pick up any new checkins. After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working We want to make sure it is still relatively easy for XFree86 to pull in new versions of the DRM. If we're making a shellscript to translate our files into the kernel's structure, maybe one to do the same job for XFree86 is sensible. Indeed Keith. I'd also like to mention that the Imakefile's or Makefile.linux/bsd will still need to be in some form in these three directories. xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel The reason being is that this new drm module is more than likely going to get imported into... xc/extras/drm and then symlinked into the original directories with the Imakefile during the XFree86 build process. Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
I mostly kept out of this discussion, so I may not quite be up-to-speed. Feel free to ignore my comments. On Tue, 16 Mar 2004 20:06:32 -0800 (PST) Jon Smirl [EMAIL PROTECTED] wrote: This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree You will also need to fix MesaSrcDir make World I assume DRMSrcDir used for finding the DRM headers. Or will the DRI build system continue to build the DRM? dri branches will also need to apply this patch I don't like that. Can branches still keep their own copy of the old DRM? I'm particulary thinking of the s3virge branch which is unmaintained at the moment. I'm not sure if it even builds, but if it does it would be nice to keep it that way until someone picks it up. You don't need to remove the DRM directories from the CVS repository to get rid of them on the trunk. You could just cvs rm the files. If you checkout/update the trunk with -P the empty directories will be purged from your working copy. I tried to patch up the bsd build but I don't run bsd so could someone please check it. Give me feedback and I can adjust the drm directory structure or the patch. When everyone likes the new setup I will commit the patch. It will only take a minute to do the switch over, I'll recopy the drm CVS v files when switching to pick up any new checkins. After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working = Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
Michel Dnzer wrote: On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote: Jon Smirl wrote: This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree You will also need to fix MesaSrcDir make World dri branches will also need to apply this patch Why? What happens on the trunk shouldn't affect them. That's the point of a branch. :) Checkout still fails: [...] Same here. After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working We want to make sure it is still relatively easy for XFree86 to pull in new versions of the DRM. If we're making a shellscript to translate our files into the kernel's structure, maybe one to do the same job for XFree86 is sensible. I'm inclined to consider this their problem... Hmm. It doesn't cost us anything to tie up loose ends. We've effectively done this with the Mesa drivers - kept a working build system in the DRI tree so that a Mesa+Drivers living in extras/ can be linked and built in an XFree86 tree. Doing the same thing for DRM is an easy step we should take so that this has a fighting chance of getting into XFree86 CVS. If you're going to argue that XFree86 CVS is suddenly not relevent, I'd counter that some fork or other offshoot of that codebase is or will become relevent, so the same argument applies. For the meantime, I'd like to keep the DRI tree buildable with a Mesa/ and now DRM/ tree hanging around as crutches. In the future, when we can build DRI drivers out of the Mesa tree, I'd still like to see us export releases from Mesa (eg. 6.0.1? or 6.1?) into the DRI tree extras/ directory and bring the build system uptodate at that point. Eventually, if/when we are doing *NO* development in what's left of DRI CVS, then sure, let's let it die. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote: Jon Smirl wrote: This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree You will also need to fix MesaSrcDir make World dri branches will also need to apply this patch Why? What happens on the trunk shouldn't affect them. That's the point of a branch. :) Checkout still fails: [...] Same here. After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working We want to make sure it is still relatively easy for XFree86 to pull in new versions of the DRM. If we're making a shellscript to translate our files into the kernel's structure, maybe one to do the same job for XFree86 is sensible. I'm inclined to consider this their problem... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wed, 2004-03-17 at 13:23, Keith Whitwell wrote: Michel Dnzer wrote: On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote: Jon Smirl wrote: After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working We want to make sure it is still relatively easy for XFree86 to pull in new versions of the DRM. If we're making a shellscript to translate our files into the kernel's structure, maybe one to do the same job for XFree86 is sensible. I'm inclined to consider this their problem... Hmm. It doesn't cost us anything to tie up loose ends. We've effectively done this with the Mesa drivers - kept a working build system in the DRI tree so that a Mesa+Drivers living in extras/ can be linked and built in an XFree86 tree. Doing the same thing for DRM is an easy step we should take so that this has a fighting chance of getting into XFree86 CVS. If you're going to argue that XFree86 CVS is suddenly not relevent, I'd counter that some fork or other offshoot of that codebase is or will become relevent, so the same argument applies. I don't see much benefit of the DRM code being in any X tree. On the contrary, I think it rather increases the support burden by increasing the chance of people running outdated code. I think the priority should be well-maintained DRM code in the kernels, so ideally people shouldn't have to worry about it at all. Failing that, they can now get the real deal from us easily. Just my opinion, if someone wants to put in the effort, that's fine with me. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Wed, 2004-03-17 at 13:23, Keith Whitwell wrote: Michel Dänzer wrote: On Wed, 2004-03-17 at 10:14, Keith Whitwell wrote: Jon Smirl wrote: After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working We want to make sure it is still relatively easy for XFree86 to pull in new versions of the DRM. If we're making a shellscript to translate our files into the kernel's structure, maybe one to do the same job for XFree86 is sensible. I'm inclined to consider this their problem... Hmm. It doesn't cost us anything to tie up loose ends. We've effectively done this with the Mesa drivers - kept a working build system in the DRI tree so that a Mesa+Drivers living in extras/ can be linked and built in an XFree86 tree. Doing the same thing for DRM is an easy step we should take so that this has a fighting chance of getting into XFree86 CVS. If you're going to argue that XFree86 CVS is suddenly not relevent, I'd counter that some fork or other offshoot of that codebase is or will become relevent, so the same argument applies. I don't see much benefit of the DRM code being in any X tree. On the contrary, I think it rather increases the support burden by increasing the chance of people running outdated code. I think the priority should be well-maintained DRM code in the kernels, so ideally people shouldn't have to worry about it at all. Failing that, they can now get the real deal from us easily. Just my opinion, if someone wants to put in the effort, that's fine with me. I agree. xfree86 doesn't ship agpgart, but that's needed for most drms; same with other kernel services. besides at the rate xfree86 makes releases, the kernel is more likely to have up to date code. it's kernel code, when not just rely on the kernel for it. Alex -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wed, Mar 17, 2004 at 09:07:12AM -0800, Jon Smirl wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: I'd also like to mention that the Imakefile's or Makefile.linux/bsd will still need to be in some form in these three directories. xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel The reason being is that this new drm module is more than likely going to get imported into... xc/extras/drm and then symlinked into the original directories with the Imakefile during the XFree86 build process. Please don't do the individual file symlinking again. It makes the build process very fragile. For example if I add a new include file to the drm project individual symlinks will make me need to patch up the Imakefile file in all of the dri branches. Linking directories is ok. The changes I made to mesa impacted all of the dri branches because of the individual symlinks. The Mesa tree is external to the dri tree; dri branches do not insulate you from external changes. Directory symlinks are better at isolating things. With directory symlinks addition of a new file doesn't break things. Of course if we add a new directory things will break again. The best isolation is a single symlink to the top of the external tree and then use makefiles that are stored in the external tree. May I suggest you provide an Imakefile that does what your suggesting ? Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
I think I've fixed all the directory permissions now. Give it try and let me know. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
Michel Dnzer wrote: Jon Smirl wrote: dri branches will also need to apply this patch Why? What happens on the trunk shouldn't affect them. That's the point of a branch. :) I believe the intention is to *move* the ,v files. If that happens, the files will disappear from all branches. That said, I don't think moving (as opposed to copying) the ,v files is a good idea. We still want 'cvs co -D somedate xc' to work. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wednesday 17 March 2004 05:12, Felix Kühling wrote: dri branches will also need to apply this patch I don't like that. Can branches still keep their own copy of the old DRM? I'm particulary thinking of the s3virge branch which is unmaintained at the moment. I'm not sure if it even builds, but if it does it would be nice to keep it that way until someone picks it up. I just checked. It doesn't. make[6]: *** No rule to make target `../shared/at_scancode.c', needed by `at_scancode.c'. Stop. etc. However, Jon has done the right thing by saying this is what branches need to do to get working again. They shouldn't need to patch _now_, but knowing what needs to be done in the future makes it possible to revive sleeping branches. I think CVSBranches on the wiki needs to be reorganized into several sections (current, sleeping, and obsolete) to reflect this; current would stay about the same, sleeping would be things like savage and s3virge, and obsolete would be merged branches (r200) or abandoned branches (dmx, smt). The sleeping ones could be annotated with links to mailing list posts describing the major changes. If that sounds acceptable, let me know so I can rework CVSBranches. - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
ajax wrote: On Wednesday 17 March 2004 05:12, Felix Kühling wrote: dri branches will also need to apply this patch I don't like that. Can branches still keep their own copy of the old DRM? I'm particulary thinking of the s3virge branch which is unmaintained at the moment. I'm not sure if it even builds, but if it does it would be nice to keep it that way until someone picks it up. I just checked. It doesn't. make[6]: *** No rule to make target `../shared/at_scancode.c', needed by `at_scancode.c'. Stop. etc. However, Jon has done the right thing by saying this is what branches need to do to get working again. They shouldn't need to patch _now_, but knowing what needs to be done in the future makes it possible to revive sleeping branches. I think CVSBranches on the wiki needs to be reorganized into several sections (current, sleeping, and obsolete) to reflect this; current would stay about the same, sleeping would be things like savage and s3virge, and obsolete would be merged branches (r200) or abandoned branches (dmx, smt). The sleeping ones could be annotated with links to mailing list posts describing the major changes. If that sounds acceptable, let me know so I can rework CVSBranches. This seems reasonable to me... Thanks for taking this on. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wed, 17 Mar 2004 09:46:30 -0800 (PST) Jon Smirl [EMAIL PROTECTED] wrote: I am copying the v files. The branches get impact via single file symlinks as I explained in other mail. Only branches which use the external DRM. Branches that still have their own internal one should not be affected. As an analogy: Branches with their own internal copy of Mesa sources were not affected by the changes that moved 3D drivers to Mesa CVS and removed the Mesa source code from xc/extras/Mesa in DRI CVS. Felix After the switch I will use cvs rm on them. --- Ian Romanick [EMAIL PROTECTED] wrote: Michel D__nzer wrote: Jon Smirl wrote: dri branches will also need to apply this patch Why? What happens on the trunk shouldn't affect them. That's the point of a branch. :) I believe the intention is to *move* the ,v files. If that happens, the files will disappear from all branches. That said, I don't think moving (as opposed to copying) the ,v files is a good idea. We still want 'cvs co -D somedate xc' to work. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wednesday 17 March 2004 13:03, Keith Whitwell wrote: I think CVSBranches on the wiki needs to be reorganized into several sections (current, sleeping, and obsolete) to reflect this; current would stay about the same, sleeping would be things like savage and s3virge, and obsolete would be merged branches (r200) or abandoned branches (dmx, smt). The sleeping ones could be annotated with links to mailing list posts describing the major changes. If that sounds acceptable, let me know so I can rework CVSBranches. This seems reasonable to me... Thanks for taking this on. No problem. I split the branches into current, sleeping, merged, and obsolete, and added a note about the DRM changes. I'll be adding more to that list shortly. In the future, if a change to the trunk requires changes in a current or sleeping branch, it should get a link on that list. Of course ideally we'd have no sleeping branches... - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
On Wed, 17 Mar 2004 12:21:36 -0600 ajax [EMAIL PROTECTED] wrote: On Wednesday 17 March 2004 05:12, Felix Kühling wrote: dri branches will also need to apply this patch I don't like that. Can branches still keep their own copy of the old DRM? I'm particulary thinking of the s3virge branch which is unmaintained at the moment. I'm not sure if it even builds, but if it does it would be nice to keep it that way until someone picks it up. I just checked. It doesn't. make[6]: *** No rule to make target `../shared/at_scancode.c', needed by `at_scancode.c'. Stop. etc. However, Jon has done the right thing by saying this is what branches need to do to get working again. They shouldn't need to patch _now_, but knowing what needs to be done in the future makes it possible to revive sleeping branches. I think CVSBranches on the wiki needs to be reorganized into several sections (current, sleeping, and obsolete) to reflect this; current would stay about the same, sleeping would be things like savage and s3virge, and obsolete would be merged branches (r200) or abandoned branches (dmx, smt). The sleeping ones could be annotated with links to mailing list posts describing the major changes. If that sounds acceptable, let me know so I can rework CVSBranches. I just read the page for the first time ;-), I think with your changes. Two corrections WRT the savage-2-0-0-branch: the savage-2-0-0-branch is merged and savage-2-0-0-fork is not a branch. It's just a tag that marks the point where the branch was started. - ajax Regards, Felix --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
Jon Smirl wrote: This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree Should the user-space access library code also be moved to the DRM tree? The code lives in program/Xserver/hw/xfree86/os-support/linux/drm/xf86drm*.c and program/Xserver/hw/xfree86/os-support/xf86drm*.h, but I think it gets symlinked to several other places during the build. The reason I ask is because the DRI drivers need this stuff to build. I don't think we want required files to keep living under xc in the DRI tree when we start building the drivers in the Mesa tree. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
The solo version of this is in Mesa/src/glx/mini. It will need to be adjusted to track whereever the X version ends up. It might even be possible to eliminate the solo version. --- Ian Romanick [EMAIL PROTECTED] wrote: Jon Smirl wrote: This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree Should the user-space access library code also be moved to the DRM tree? The code lives in program/Xserver/hw/xfree86/os-support/linux/drm/xf86drm*.c and program/Xserver/hw/xfree86/os-support/xf86drm*.h, but I think it gets symlinked to several other places during the build. The reason I ask is because the DRI drivers need this stuff to build. I don't think we want required files to keep living under xc in the DRI tree when we start building the drivers in the Mesa tree. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
I think I've fixed all the directory permissions now. Give it try and let me know. --- Keith Whitwell [EMAIL PROTECTED] wrote: cvs checkout: Updating drm/bsd/drm cvs checkout: failed to create lock directory for `/cvs/dri/drm/bsd/drm' (/cvs/dri/drm/bsd/drm/#cvs.lock): Permission denied cvs checkout: failed to obtain dir lock in repository `/cvs/dri/drm/bsd/drm' cvs [checkout aborted]: read lock failed - giving up = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
I am copying the v files. The branches get impact via single file symlinks as I explained in other mail. After the switch I will use cvs rm on them. --- Ian Romanick [EMAIL PROTECTED] wrote: Michel Dänzer wrote: Jon Smirl wrote: dri branches will also need to apply this patch Why? What happens on the trunk shouldn't affect them. That's the point of a branch. :) I believe the intention is to *move* the ,v files. If that happens, the files will disappear from all branches. That said, I don't think moving (as opposed to copying) the ,v files is a good idea. We still want 'cvs co -D somedate xc' to work. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-develel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Switching dri over to new drm tree
Have every one tried the patch I sent out for switching the dri tree over to the new drm? Are there objections to doing the switch over later tonight? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
--- Alan Hourihane [EMAIL PROTECTED] wrote: May I suggest you provide an Imakefile that does what your suggesting ? Already did. The patch I sent out works that way for drm. Alan. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Switching dri over to new drm tree
--- Alan Hourihane [EMAIL PROTECTED] wrote: I'd also like to mention that the Imakefile's or Makefile.linux/bsd will still need to be in some form in these three directories. xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel The reason being is that this new drm module is more than likely going to get imported into... xc/extras/drm and then symlinked into the original directories with the Imakefile during the XFree86 build process. Please don't do the individual file symlinking again. It makes the build process very fragile. For example if I add a new include file to the drm project individual symlinks will make me need to patch up the Imakefile file in all of the dri branches. Linking directories is ok. The changes I made to mesa impacted all of the dri branches because of the individual symlinks. The Mesa tree is external to the dri tree; dri branches do not insulate you from external changes. Directory symlinks are better at isolating things. With directory symlinks addition of a new file doesn't break things. Of course if we add a new directory things will break again. The best isolation is a single symlink to the top of the external tree and then use makefiles that are stored in the external tree. Alan. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Switching dri over to new drm tree
This patch switches the dri build over to use the new standalone drm tree. You will need to check out the new drm tree from the dri CVS root Apply the patch to dri DRMSrcDir in config/cf/host.def needs to be edited to point to your copy of the drm tree You will also need to fix MesaSrcDir make World dri branches will also need to apply this patch I tried to patch up the bsd build but I don't run bsd so could someone please check it. Give me feedback and I can adjust the drm directory structure or the patch. When everyone likes the new setup I will commit the patch. It will only take a minute to do the switch over, I'll recopy the drm CVS v files when switching to pick up any new checkins. After the switch I can remove these directories from dri: /xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel /xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel Delete these locally if you want to make sure the patch is working = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com patch Description: patch
