Re: [Dri-devel] DRM Kernel Questions
Sven Luther wrote: On Thu, Dec 12, 2002 at 07:14:45PM -0800, Philip Brown wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: ... It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. May I suggest that the best way to do that, is to keep the kernel DRM code, as a **SEPARATE PROJECT**, at least on the source code repository level. IMO, there should be a separate repository, or at least a separate directory at the same level as the top-level xc. The only thing from the driver that really belongs buried in the xfree86 server code, is a single, os-neutral copy of drm.h, from whatever version of DRM that branch of xfree86 is officially supporting. Once you have achieved that separation, you have something actually resembling a formal API between user-level and kernel driver level. That is the only way things are going to get cleaned up, process-wise. Not to mention greatly aiding kernel coding efforts for non-linux platforms. And there are also people wanting to use the DRM outside of XFree86, maybe even outside of the DRI, not sure though. This is true: I'm working (in Mesa CVS, atm) on an embedded radeon 3d driver that lives on top of fbdev, for instance. (There was the fb_dri project that achieved similar goals, but not very cleanly). It's clear that both the drm and the 3d clientside drivers have a life outside XFree86, but what isn't clear is how to express this in a reasonable development environment or set of CVS trees. Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Fri, Dec 13, 2002 at 10:18:44AM +, Keith Whitwell wrote: ... It's clear that both the drm and the 3d clientside drivers have a life outside XFree86, but what isn't clear is how to express this in a reasonable development environment or set of CVS trees. Well, lets work on making things clear, then :-) Whats wrong with my proposal of moving it to the top level? eg: accessing it by means of cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri co drm --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Alan Hourihane wrote: On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote: Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Linus should submit it here for inclusion - simple. I doubt any of us are tracking 2.5.x that closely at the moment. Note that the standard kernel does _not_ have any new DRM stuff (it does in fact tend to lag behind the DRI CVS tree a bit). If 2.5.x is smoother, it is because of other issues (most likely the higher timer frequency). I've submitted a few patches to just make merging the DRI CVS tree easier (ie whitespace fixes from the standard tree), and those got merged pretty quickly by Keith, if I remember correctly. On the whole 2.5.x has usually tracked the DRI CVS tree _fairly_ well. I haven't had any real troubles merging stuff (yeah, I didn't want to merge the task-queue changes, but that already got discussed, and the current DRI tree may even have the objectionable stuff fixed - I just came back from two days in Korea, so I haven't had time to check). My only worry about the DRI CVS tree is one of stability and timing - it would be nice if the kernel part of DRI were to be fairly good and backwards compatible by say March 2003, simply because we'll have 2.6 coming up, and if the in-kernel DRI code is to be useful, it would hopefully work both with older X setups _and_ the DRI CVS tree.. In short, I'm pretty happy with DRI CVS. It's not a huge amount of work for me to merge stuff from there (assuming it keeps goign like it has so far), and my historical worries (the lack of binary compatibility etc) seem to have been addressed quite nicely and I have absolutely no complaints. Linus --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). That would mean the DRM of the day gets more exposure to external review and we find bugs in the kernel side (be they X or kernel caused) rapidly, as well as submitting back changes to the common repository so that when a new major Linux kernel appears DRM just works. Alan --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Alan. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. My feeling is that the dri cvs should be that place. What workable alternatives exist? It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). This is the biggest unknown, I think - there are multiple sources that have a reasonable claim to this throne -- whatever was in the last XFree86 release -- XFree86 stable cvs (which differs only slightly from above) -- the newly created dri stable branch -- etc. We've had some discussions about stable branches for other purposes (binary compatibility concerns with XFree versions), however it would make reasonable sense for this to be the definitive 'stable' source for drm modules also. That would mean the DRM of the day gets more exposure to external review and we find bugs in the kernel side (be they X or kernel caused) rapidly, as well as submitting back changes to the common repository so that when a new major Linux kernel appears DRM just works. We've been very lucky in that Linus has been pulling changes into 2.5 and providing some useful feedback when things go wrong. I don't know how sustainable this is though - I think we're probably taking up more of his time than we should be. How would you ideally see this working? Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Or 4.2.x for most recent x? What about bugs that are found in the modules after XFree is released? Or api changes within the kernel? Sorry - yes 4.2.1 or most recent 4.2.x. As for bugs found or api changes they should be submitted back to XFree86 so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x release - if there was to be one. Alan. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Or 4.2.x for most recent x? What about bugs that are found in the modules after XFree is released? Or api changes within the kernel? Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Am Donnerstag, 12. Dezember 2002 13:58 schrieb Alan Hourihane: On Thu, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Or 4.2.x for most recent x? What about bugs that are found in the modules after XFree is released? Or api changes within the kernel? Sorry - yes 4.2.1 or most recent 4.2.x. As for bugs found or api changes they should be submitted back to XFree86 so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x release - if there was to be one. Sorry, but I think this is much to slow/few. Look at the current kernel (drm) source. There are daily changes/fixes and we should use the latest XFree (DRI) DRM? Currently I'm under the impression that nobody (only a few) of the XFree/DRI developers pay attention about SMP and/or latency where some Linux kernel affords go. Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell for some apps on my SMP system. Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Only some thoughts. -Dieter --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Sorry, but I think this is much to slow/few. Look at the current kernel (drm) source. There are daily changes/fixes and we should use the latest XFree (DRI) DRM? Currently I'm under the impression that nobody (only a few) of the XFree/DRI developers pay attention about SMP and/or latency where some Linux kernel affords go. Well, that's the problem that we're addressing -- the changes from different people are going to different places, so there's no single good source. Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote: Am Donnerstag, 12. Dezember 2002 13:58 schrieb Alan Hourihane: On Thu, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Or 4.2.x for most recent x? What about bugs that are found in the modules after XFree is released? Or api changes within the kernel? Sorry - yes 4.2.1 or most recent 4.2.x. As for bugs found or api changes they should be submitted back to XFree86 so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x release - if there was to be one. Sorry, but I think this is much to slow/few. The speed of updates wasn't the original question, it was where to get the right stable or development DRM modules. Look at the current kernel (drm) source. There are daily changes/fixes and we should use the latest XFree (DRI) DRM? Currently I'm under the impression that nobody (only a few) of the XFree/DRI developers pay attention about SMP and/or latency where some Linux kernel affords go. If people decided to upgrade their kernel, they'd already get a later DRM that should function with the latest XFree86 4.2.x release regardless of whether the DRI trunk DRM modules have anything to do with it. Thus getting whatever bug fixes are in the later kernel. Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell for some apps on my SMP system. Forget the DRI trunk for a second, what does 2.4.20 do with XFree86 4.2.x ? That should be stable. As for your question, have you posted more details on the problem ? Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Linus should submit it here for inclusion - simple. I doubt any of us are tracking 2.5.x that closely at the moment. Alan. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Don, 2002-12-12 at 14:50, Dieter Nützel wrote: Look at the current kernel (drm) source. There are daily changes/fixes and we should use the latest XFree (DRI) DRM? Currently I'm under the impression that nobody (only a few) of the XFree/DRI developers pay attention about SMP and/or latency where some Linux kernel affords go. Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell for some apps on my SMP system. Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. As Keith pointed out, we can't track all the DRM changes outside of our tree. We need the people making those changes submitting them to us, which happens rarely, if ever. I'd appreciate a lot if it did. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote: It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. There should at the least be one person on the DRI team who looks at each new kernel releases with a Are there any changes here I need to push into DRI CVS mindset. This job doesn't need you to even monitor l-k, just keep an eye on each release Linus does. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote: Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Linus should submit it here for inclusion - simple. I doubt any of us are tracking 2.5.x that closely at the moment. I'm surprised Linus finds the time to do the DRI merges he does already. Pushing stuff back to DRI-devel is going to take up even more of his time, so this should ideally be done by someone else, preferably someone who really understands the code. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Dave Jones wrote: On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote: Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Linus should submit it here for inclusion - simple. I doubt any of us are tracking 2.5.x that closely at the moment. I'm surprised Linus finds the time to do the DRI merges he does already. Pushing stuff back to DRI-devel is going to take up even more of his time, so this should ideally be done by someone else, preferably someone who really understands the code. Yes. What Linus does is above and beyond what we could/should reasonably expect. Asking him to do more isn't an option. Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Am Donnerstag, 12. Dezember 2002 15:09 schrieb Alan Hourihane: On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote: Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell for some apps on my SMP system. Forget the DRI trunk for a second, what does 2.4.20 do with XFree86 4.2.x ? That should be stable. As for your question, have you posted more details on the problem ? See [Dri-devel] radeon.o DRM modules breaks my CD player (!) thread. -Dieter --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Keith Whitwell wrote: Right now for 2.4 I'm juggling too many conflicting balls, if its all in the DRM CVS then merging stuff added to DRM cvs is a real nobrainer, and since I can do it item by item as it changes its also easy to know when something bad happens. I've been looking at what's in 2.4 and it's quite divergent from what we've got on the trunk. It is pretty closely related to the xfree 4.2 code, though, and most of the changes seem to be in the 2.4 code. Are you proposing pulling the dri trunk code into 2.4? Is the DRI trunk compatible with XFree86 4.1.0, 4.2.0, 4.2.1, and current CVS XFree86? If so, and it is considered stable, which is what I presume by it being considered for 2.4.x integration, then it makes sense to me to do so. Backward compatibility with releases back at least as far as 4.1.0 is critically important though. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Dave Jones wrote: On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote: It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. There should at the least be one person on the DRI team who looks at each new kernel releases with a Are there any changes here I need to push into DRI CVS mindset. This job doesn't need you to even monitor l-k, just keep an eye on each release Linus does. I'm running through the differences between dri trunk and 2.5.51 now, with the aim of pulling stuff back. So far nothing huge has jumped out at me. Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Dave Jones wrote: On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote: It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. There should at the least be one person on the DRI team who looks at each new kernel releases with a Are there any changes here I need to push into DRI CVS mindset. This job doesn't need you to even monitor l-k, just keep an eye on each release Linus does. Dave, I expect the changes Linus makes will run with the kernels he releases, but my question is, will they work with older kernels, too? The DRI cvs sources need to support those as well? Supporting DRM under stable and development XFree86 as well as stable and development Linux Kernel seems like a large job when your consider compatability with older releases (of XFree86 and kernel), the number of drivers, and the code being shared with other operating systems. My point is this may require more of an effort than simply merging Linus' changes back into the DRI tree. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. I would love to see this as well. I am not sure that this two tree CVS devel method is the most efficient. I am sure it was started for good reasons, but I think it taxes some time for people like me who try keep testing the big picture by running both trees in one. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). I like that idea ... essentially two copies of DRM in the kernel tree. One that is visible always as it is considered most stable with the current release of XFree86 and the running experimental version. Admittably the compatibility with modules also depends on what version of XFree86 as you noted above - it sure ... complicates things. I guess at some point we have to believe that if you are building your own kernel that you are reasonably competent to figure that one out. Not always the case, but unfortunately it is so hard to check the intelligence sitting in front of the console with a configuring script. ;-) For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. I admit that your logic is sound, but answer me this: Does one send the changes back on the stable to the XFree86 team proper or to the DRI team? The two group devel model gets kinda unwieldy at this point. Right now most vendors have to track the individual patches to XFree86 and DRI in between releases ... and they kinda push the changes back into the code base where they belong when they can. Surely we can thing of a better way to do the tango to help everyone out ... -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: ... It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. May I suggest that the best way to do that, is to keep the kernel DRM code, as a **SEPARATE PROJECT**, at least on the source code repository level. IMO, there should be a separate repository, or at least a separate directory at the same level as the top-level xc. The only thing from the driver that really belongs buried in the xfree86 server code, is a single, os-neutral copy of drm.h, from whatever version of DRM that branch of xfree86 is officially supporting. Once you have achieved that separation, you have something actually resembling a formal API between user-level and kernel driver level. That is the only way things are going to get cleaned up, process-wise. Not to mention greatly aiding kernel coding efforts for non-linux platforms. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 11:11:13AM -0600, D. Hageman wrote: On Thu, 12 Dec 2002, Alan Hourihane wrote: For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. I admit that your logic is sound, but answer me this: Does one send the changes back on the stable to the XFree86 team proper or to the DRI team? The two group devel model gets kinda unwieldy at this point. Right now most vendors have to track the individual patches to XFree86 and DRI in between releases ... and they kinda push the changes back into the code base where they belong when they can. I'd send stability changes directly to XFree86. Then the changes would go straight into the stable branch of XFree86. There's a close working relationship between the two groups anyway and if the XFree86 team want a quick response from the DRI folks on a patch they've received then that would happen. Alan. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 2002-12-12 at 12:40, Alan Hourihane wrote: The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them for things pci_alloc_consistent ? --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On 12 Dec 2002, Alan Cox wrote: Date: 12 Dec 2002 18:22:10 + From: Alan Cox [EMAIL PROTECTED] To: Alan Hourihane [EMAIL PROTECTED] Cc: D. Hageman [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Type: text/plain List-Id: dri-devel.lists.sourceforge.net Subject: Re: [Dri-devel] DRM Kernel Questions On Thu, 2002-12-12 at 12:40, Alan Hourihane wrote: The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them for things pci_alloc_consistent ? I don't know the answer to that, but it brought up a thought in my mind. DRM is supposed to be backward compatible currently as far back as 4.1.0. It would make the most sense to me then, to check all DRM changes into xf-4_2-branch, and xf-4_1-branch as soon as they're known to be stable and correct. This ensures that DRM is updated in all releases. The alternative is having people get a given X release, and then use the DRM from the most recent X release. Or should they be getting it from DRI-CVS instead? Or from kernel.org? A lot of confusion in DRMland... -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 2002-12-12 at 12:49, Keith Whitwell wrote: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. My feeling is that the dri cvs should be that place. What workable alternatives exist? That seems right. It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. Thats why I said its not just about what we need. Ok so DRI CVS is definitive and has branches for 4.2.0/4.2.1/devel. So if I make sure all the Linux changes to 2.4.x DRM get channeled back to this list they can get reviewed and merged back and we are all happy. Thats trivial for me to do since I'm already seeing each patch that touches that area. We've been very lucky in that Linus has been pulling changes into 2.5 and providing some useful feedback when things go wrong. I don't know how sustainable this is though - I think we're probably taking up more of his time than we should be. How would you ideally see this working? Mostly I want to know how to make sure changes stick once they are made and deemed or shown to work. If the Linux fixes get back into the DRM CVS, then the only other bit is knowing when the DRM CVS has changed. That sounds like a procmail filter on the commit notify list for DRI if there is one set up. Right now for 2.4 I'm juggling too many conflicting balls, if its all in the DRM CVS then merging stuff added to DRM cvs is a real nobrainer, and since I can do it item by item as it changes its also easy to know when something bad happens. Alan --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Alan Hourihane wrote: The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them for things pci_alloc_consistent ? No, nor does 4.2.1. Should anyone be using XFree86 CVS stable branch DRM nor trunk DRM then? I presume if bugfixes are not going into XFree86 CVS stable branches, that the DRM in there is snapshoted and then throwaway. Where should we be getting DRM from for our kernel, and where should we be sending bug fixes for DRM to? I'd like to have one single location, be it kernel.org, DRI-CVS, or XFree86.org to both get DRM from, and send in bugfixes for. I have been getting it from XFree86 CVS in the past, generally right after a merge, or when I spot drm changes in cvs-commits. Right now however, for both Red Hat kernels, and kernel.org kernels there is up to 2 levels of indirection between the kernel.org kernel updates and the DRM upstream source, and it seems also that many bugfixes also go through 2 or more levels of indirection. Where should all DRM bug fixes be sent? Right now if I've got a DRM bugfix hypothetically, I've got to send it to Arjan for inclusion in our kernel, then Alan or Marcelo for inclusion in the kernel.org kernel, and should probably have it sent to linux-kernel so other vendors are aware of it also, then dri-devel to make DRI developers aware of it for inclusion into DRI CVS too, as I understand nobody follows linux-kernel, and also to XFree86's patch queue. It's impossible to track all of that, and to track wether or not a given patch has actually been accepted in all of those locations and is applied or not. It's possible that one group of people may not apply the patch until it is accepted by group B or C, and that the submitter may be expected to monitor group B to see if they accept and apply it, and then again notify group A, C and D that the patch is applied, please apply it to your set too. As the number of patches goes up, and the number of releases of the kernel, XFree86, our distro, etc. it is impossible to keep track of it all. What I would like to see, is the DRI project, the XFree86 project, the Linux kernel folk all agree to one single unmistakeable official location for acquiring the current official stable kernel DRM source, and one single official location for submitting bug fixes, and then either: 1) That one location is responsible for pushing the fix out to whatever other places they feel are necessary or warranted. or 2) The various projects all pull the fixes in themselves from the one single central 'official' location, and if sent a fix from someone randomly, they automatically forward it on to the official location and not just apply it locally to their tree. That could be DRI-CVS, XFree86 CVS, or kernel.org. Also, it'd be prefered if that one official location would release versioned tarballs of the official DRM release, which would then be easier for people to manage what changed between different versions than tracking a given CVS head which may possibly become unstable at some times, etc. Right now, as it stands, I often get bug reports of DRI lockups and problems in our bugzilla, which upon deeper investigation turns out to be someone using a kernel.org kernel instead of our supplied kernel, and the DRM isn't new enough, or contains bugs that our kernel does not, and that DRI-CVS or XFree86 might not. We need... One DRM to rule them all, One developer to find them, One DRM to bring them all, And in the darkness find them. dodges tomatoes Yes, that was a lame attempt at humor. Seriously though, having 50 frayed trees of the same source code benefits nobody really, especially if various people consider different trees as authoritative/stable/official/whatever. As long as XFree86 / DRI Project / kernel.org each have their own DRM code, people will pull DRM from one of the three locations, and people will send bug reports, fixes, etc. to 3 locations. If each of those locations refuse to send patches on to the other locations, and expect the submitter to do it, the whole thing breaks down. What solutions do people think would be appropriate? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Mike A. Harris wrote: On Thu, 12 Dec 2002, Alan Hourihane wrote: The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them for things pci_alloc_consistent ? No, nor does 4.2.1. Should anyone be using XFree86 CVS stable branch DRM nor trunk DRM then? I presume if bugfixes are not going into XFree86 CVS stable branches, that the DRM in there is snapshoted and then throwaway. This is pretty much what my claim was the other day when we were talking on IRC ... one needs to see the DRI stuff moved into the XFree86 CVS tree on a regular basis to see any decent results. This is why I take the time to merge in the DRI stuff everytime I build new RPMs to test XFree86 code. Changes to the XFree86 code proper seems to not be getting moved over as quickly as it should. If we want to take a recent example - we can use the xf86strncat symbol missing out of the loader code. The issue was first noticed in the DRI tree, but the change didn't get put into the XFree86 tree until about two weeks later ... and then it was just because I happened to make an off hand comment about it on the xfree86-devel list. I checked the vendor and what not tags on the RPMs I built for myself and you are correct that they are undefined. I really like that new version of RPM. It does nice things [tm]. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, Dec 12, 2002 at 07:14:45PM -0800, Philip Brown wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: ... It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. May I suggest that the best way to do that, is to keep the kernel DRM code, as a **SEPARATE PROJECT**, at least on the source code repository level. IMO, there should be a separate repository, or at least a separate directory at the same level as the top-level xc. The only thing from the driver that really belongs buried in the xfree86 server code, is a single, os-neutral copy of drm.h, from whatever version of DRM that branch of xfree86 is officially supporting. Once you have achieved that separation, you have something actually resembling a formal API between user-level and kernel driver level. That is the only way things are going to get cleaned up, process-wise. Not to mention greatly aiding kernel coding efforts for non-linux platforms. And there are also people wanting to use the DRM outside of XFree86, maybe even outside of the DRI, not sure though. Friendly, Sven Luther --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? On Wed, 11 Dec 2002, Alan Cox wrote: On Wed, 2002-12-11 at 20:12, D. Hageman wrote: I have noticed some feedback from Alan and Linus already on this list. Is anyone taking care of things yet? No. There isnt currently a nice setup for this. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
