From: D. H. <dha...@dr...> - 2002-12-11 20:19:14
|
I was talking on the dri-devel channel with Mike Harris and a few questions popped up concerning DRM and the Kernel. Who is the lead guy that takes care of the DRM stuff? Stuff being pulling it out of CVS occasionally to submit to Linus, Alan, etc. for inclusion in the kernel and making sure everything is up to par with what they want from their feedback. I have noticed some feedback from Alan and Linus already on this list. Is anyone taking care of things yet? -- //========================================================\\ || D. Hageman <dha...@dr...> || \\========================================================// |
From: Alan C. <al...@lx...> - 2002-12-11 20:51:21
|
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. |
From: D. H. <dha...@dr...> - 2002-12-11 22:18:53
|
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 > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- //========================================================\\ || D. Hageman <dha...@dr...> || \\========================================================// |
From: Alan C. <al...@lx...> - 2002-12-12 12:28:59
|
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 |
From: Alan H. <al...@fa...> - 2002-12-12 12:40:44
|
On Thu, Dec 12, 2002 at 01:02:30PM +0000, 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. |
From: Alan C. <al...@lx...> - 2002-12-12 17:49:13
|
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 ? |
From: Alan H. <al...@fa...> - 2002-12-12 17:51:43
|
On Thu, Dec 12, 2002 at 06:22:10PM +0000, Alan Cox wrote: > 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 ? No, nor does 4.2.1. Alan. |
From: Mike A. H. <mh...@re...> - 2002-12-12 19:20:25
|
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 |
From: D. H. <dha...@dr...> - 2002-12-12 19:33:02
|
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 <dha...@dr...> || \\========================================================// |
From: Mike A. H. <mh...@re...> - 2002-12-12 18:40:04
|
On 12 Dec 2002, Alan Cox wrote: >Date: 12 Dec 2002 18:22:10 +0000 >From: Alan Cox <al...@lx...> >To: Alan Hourihane <al...@fa...> >Cc: D. Hageman <dha...@dr...>, dri...@li... >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 |
From: Keith W. <ke...@tu...> - 2002-12-12 12:57:06
|
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 |
From: Dave J. <da...@su...> - 2002-12-12 14:28:31
|
On Thu, Dec 12, 2002 at 12:49:37PM +0000, 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 |
From: Keith W. <ke...@tu...> - 2002-12-12 15:32:45
|
Dave Jones wrote: > On Thu, Dec 12, 2002 at 12:49:37PM +0000, 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 |
From: Jens O. <je...@tu...> - 2002-12-12 16:07:04
|
Dave Jones wrote: > On Thu, Dec 12, 2002 at 12:49:37PM +0000, 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 / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Alan C. <al...@lx...> - 2002-12-12 18:44:14
|
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 |
From: Philip B. <ph...@bo...> - 2002-12-13 03:14:48
|
On Thu, Dec 12, 2002 at 01:02:30PM +0000, 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. |
From: Sven L. <lu...@dp...> - 2002-12-13 07:13:26
|
On Thu, Dec 12, 2002 at 07:14:45PM -0800, Philip Brown wrote: > On Thu, Dec 12, 2002 at 01:02:30PM +0000, 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 |
From: Keith W. <ke...@tu...> - 2002-12-13 10:18:35
|
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 +0000, 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 |
From: Philip B. <ph...@bo...> - 2002-12-13 19:22:54
|
On Fri, Dec 13, 2002 at 10:18:44AM +0000, 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:ano...@cv...:/cvsroot/dri co drm |
From: Keith W. <ke...@tu...> - 2002-12-12 13:01:25
|
Alan Hourihane wrote: > On Thu, Dec 12, 2002 at 01:02:30PM +0000, 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 |
From: Alan H. <al...@fa...> - 2002-12-12 12:59:42
|
On Thu, Dec 12, 2002 at 12:53:46PM +0000, Keith Whitwell wrote: > Alan Hourihane wrote: > >On Thu, Dec 12, 2002 at 01:02:30PM +0000, 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. |
From: Dieter <Die...@ha...> - 2002-12-12 13:50:55
|
Am Donnerstag, 12. Dezember 2002 13:58 schrieb Alan Hourihane: > On Thu, Dec 12, 2002 at 12:53:46PM +0000, Keith Whitwell wrote: > > Alan Hourihane wrote: > > >On Thu, Dec 12, 2002 at 01:02:30PM +0000, 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 |
From: Keith W. <ke...@tu...> - 2002-12-12 14:24:40
|
> 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 |
From: Michel <mi...@da...> - 2002-12-12 14:27:18
|
On Don, 2002-12-12 at 14:50, Dieter N=FCtzel wrote: > Look at the "current" kernel (drm) source. > There are "daily" changes/fixes and we should use the "latest" XFree (DRI= )=20 > DRM? Currently I'm under the impression that nobody (only a few) of the=20 > XFree/DRI developers pay attention about SMP and/or latency where some Li= nux=20 > kernel affords go. >=20 > Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like h= ell=20 > for some apps on my SMP system. >=20 > Some apps only run smooth with 2.5.49+ kernels due to Linus latest work.=20 > 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. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
From: Alan H. <al...@fa...> - 2002-12-12 14:22:12
|
On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter N=FCtzel wrote: > Am Donnerstag, 12. Dezember 2002 13:58 schrieb Alan Hourihane: > > On Thu, Dec 12, 2002 at 12:53:46PM +0000, Keith Whitwell wrote: > > > Alan Hourihane wrote: > > > >On Thu, Dec 12, 2002 at 01:02:30PM +0000, 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 do= ne.=20 > > > >>> 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 d= o they > > > >>need. > > > >> > > > >>What I would like to see would be: > > > >> > > > >>A single definitive source for the DRM code, one where contributi= ons 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 pe= ople - > > > >>perhaps the devel kernel tree having an option for "Development D= RM > > > >>(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 tr= unk. > > > > > > 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 XFr= ee86 > > 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. >=20 > 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 (D= RI)=20 > DRM? Currently I'm under the impression that nobody (only a few) of the= =20 > XFree/DRI developers pay attention about SMP and/or latency where some = Linux=20 > kernel affords go. =20 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 getti= ng whatever bug fixes are in the later kernel. > Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like= hell=20 > 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= .=20 > 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. |