Re: RFC: libdrm repo
Hi, On Sat, Nov 28, 2009 at 08:40:55PM -0800, vehemens wrote: On Saturday 28 November 2009 16:21:58 Robert Noland wrote: Because unpublished work doesn't exist That goes for the work that I've done that isn't yet published as well. Until it is in the hands of someone besides yourself it is irrelevant. Thats the whole point of having a public respository. How else can one publish? gitorious, github, people.fd.o, freebsd.org public_html, etc, etc. Cheers, Daniel pgpLz1f0MtR1U.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sat, 2009-11-28 at 20:40 -0800, vehemens wrote: On Saturday 28 November 2009 16:21:58 Robert Noland wrote: On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: On Saturday 28 November 2009 10:41:39 Robert Noland wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. Because unpublished work doesn't exist That goes for the work that I've done that isn't yet published as well. Until it is in the hands of someone besides yourself it is irrelevant. Thats the whole point of having a public respository. How else can one publish? Again, there is nothing that prevents you from publishing your version of the drm repo, though I don't see the point. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. I'm not sure which issue you are referring to right now. But if you mean trying to backport the work of Intel, ATI/AMD and nouveau into a repository that all of the above have now abandoned, none who currently have commit to the drm repo are willing or able to take on that task. Did you miss my plea's, rants and attempts to make valid arguments not to reorganize/abandon drm in the first place? Unfortunately, we lost that battle. It only served to increase the complexity and workload that I am faced with. However, since every major vendor has now pulled out and maintains a private linux repo for their code, the code that lived in drm git was stale, and not terribly useful for anything other than historical purposes. First you say abandoning the respository increased your workload, then you say it wasn't useful. Which is it? What increased my workload was having to go and try and pull changes from several different linux trees and try to incorporate that into some usable code base. Now, that the repo has been abandoned it is no longer useful. If vendors were still committing to the repo, we wouldn't be having this debate. If you are referring to the patches/diffs that you have sent me, then I have always appreciated the work that you have done. The last batch of stuff that you sent me, however was quite a mess. While there was some nice cleanup in it, it also contained at least some reversions of code specifically changed for FreeBSD. Even more of a problem than that was that what you sent me at the time was one big jumble and in no way represented a coherent set of patches that I could apply and commit to any repo. You did state at the time, that it was WIP, so perhaps you have a more coherent patch set now. I should have
Re: RFC: libdrm repo
On Sunday 29 November 2009 00:31:17 Daniel Stone wrote: Hi, On Sat, Nov 28, 2009 at 08:40:55PM -0800, vehemens wrote: On Saturday 28 November 2009 16:21:58 Robert Noland wrote: Because unpublished work doesn't exist That goes for the work that I've done that isn't yet published as well. Until it is in the hands of someone besides yourself it is irrelevant. Thats the whole point of having a public respository. How else can one publish? gitorious, github, people.fd.o, freebsd.org public_html, etc, etc. Well I meant in the context of the existing structure, not starting a brand new one. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 07:07:41 Robert Noland wrote: On Sat, 2009-11-28 at 20:40 -0800, vehemens wrote: On Saturday 28 November 2009 16:21:58 Robert Noland wrote: On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: On Saturday 28 November 2009 10:41:39 Robert Noland wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. Because unpublished work doesn't exist That goes for the work that I've done that isn't yet published as well. Until it is in the hands of someone besides yourself it is irrelevant. Thats the whole point of having a public respository. How else can one publish? Again, there is nothing that prevents you from publishing your version of the drm repo, though I don't see the point. Your missing the point of using a development structure which supports collobration. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. I'm not sure which issue you are referring to right now. But if you mean trying to backport the work of Intel, ATI/AMD and nouveau into a repository that all of the above have now abandoned, none who currently have commit to the drm repo are willing or able to take on that task. Did you miss my plea's, rants and attempts to make valid arguments not to reorganize/abandon drm in the first place? Unfortunately, we lost that battle. It only served to increase the complexity and workload that I am faced with. However, since every major vendor has now pulled out and maintains a private linux repo for their code, the code that lived in drm git was stale, and not terribly useful for anything other than historical purposes. First you say abandoning the respository increased your workload, then you say it wasn't useful. Which is it? What increased my workload was having to go and try and pull changes from several different linux trees and try to incorporate that into some usable code base. Now, that the repo has been abandoned it is no longer useful. If vendors were still committing to the repo, we wouldn't be having this debate. If you are referring to the patches/diffs that you have sent me, then I have always appreciated the work that you have done. The last batch of stuff that you sent me, however was quite a mess. While there was some nice cleanup in it, it also contained at least some reversions of code specifically changed for FreeBSD. Even more of a problem than that was that what you sent me at
Re: RFC: libdrm repo
I enjoy playing the devils advocate occasionally, so take this with a grain of salt. My understanding is that there are roughly 3 bsd kernels that support drm userspace interface(free*, open* and netbsd?), each has 1 or 2 maintainers. For better or worse the linux guys/girls have gone their own way. As far as i can tell kernel driver complexity has gone up in recent time, to the point where nouveau (which is a relatively small group of people too) has done the same (=move to a linux kernel tree) to avoid the significant burden of backporting. Unless the 3 bsd kernels are very similar i do not see how you expect to keep up. Instead of ranting you should ask yourself if it is even possible to unify the drm code for all forms of bsd. Accept that the majority of developers (which use linux as far as i know) have moved away from the development model that you prefer. As the devils advocate i can say that the gain for linux-drm from bsd-drm is not worth the effort of the old development model, you are (unfortunately) forced to do more work. Robert has accepted the reality, all you can try to do is spread the burden across all the bsd's. The way you're being treated is a result from the harsh reality that stems from the stalemate that the previous development model caused. No amount of complaining is going to change the fact that some people don't care about bsd. Sincerely, Maarten Maathuis. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 10:39:34 Maarten Maathuis wrote: I enjoy playing the devils advocate occasionally, so take this with a grain of salt. My understanding is that there are roughly 3 bsd kernels that support drm userspace interface(free*, open* and netbsd?), each has 1 or 2 maintainers. For better or worse the linux guys/girls have gone their own way. As far as i can tell kernel driver complexity has gone up in recent time, to the point where nouveau (which is a relatively small group of people too) has done the same (=move to a linux kernel tree) to avoid the significant burden of backporting. Unless the 3 bsd kernels are very similar i do not see how you expect to keep up. Instead of ranting you should ask yourself if it is even possible to unify the drm code for all forms of bsd. Accept that the majority of developers (which use linux as far as i know) have moved away from the development model that you prefer. As the devils advocate i can say that the gain for linux-drm from bsd-drm is not worth the effort of the old development model, you are (unfortunately) forced to do more work. Robert has accepted the reality, all you can try to do is spread the burden across all the bsd's. The way you're being treated is a result from the harsh reality that stems from the stalemate that the previous development model caused. No amount of complaining is going to change the fact that some people don't care about bsd. I believe that moving away from the current model makes it more difficult to ... spread the burden ..., hence my objections. If you want to call that ranting or complaining, so be it. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 14:16:13 vehemens wrote: [snip] Your missing the point of using a development structure which supports collobration. [snip] The difference is that you are the only one doing the work now. [snip] Again, your missing the point of using a development structure which supports collobration. [snip] It hasn't moved ... well beyond what was in drm git. If you believe otherwise, your only fooling yourself. [snip] See above comments. Yes, you have made it abundantly clear that you are in favor of having a centralized repository for all DRM development. The fact is, that's not happening now and is not going to happen. That used to be the case, but the linux DRM developers did not see an advantage to that for themselves, and though rnoland was unhappy with the decision (because it made his job harder), the linux DRM developers did what they felt was best. Since then, rnoland has made significant progress porting the linux specific changes over to FreeBSD. If you don't believe the changes he's made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm on freedesktop git then you are fooling yourself. Frankly, if I were Robert, I would be offended by that statement you made. As has been said time and again, the kernel specific code in mesa/drm serves no purpose other than providing a historical log of the DRM development from that time, so there was no harm in pulling it. The FreeBSD DRM code follows the same development model as the rest of FreeBSD, and I have a hard time believing that such a model doesn't support collaboration. That is certainly an accusation I've never once heard made against the FreeBSD project in recent years till just now. Now, the changes are made, and what's done is done. Can we please just move on? Adam -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: On Sunday 29 November 2009 14:16:13 vehemens wrote: [snip] Your missing the point of using a development structure which supports collobration. [snip] The difference is that you are the only one doing the work now. [snip] Again, your missing the point of using a development structure which supports collobration. [snip] It hasn't moved ... well beyond what was in drm git. If you believe otherwise, your only fooling yourself. [snip] See above comments. Yes, you have made it abundantly clear that you are in favor of having a centralized repository for all DRM development. The fact is, that's not happening now and is not going to happen. That used to be the case, but the linux DRM developers did not see an advantage to that for themselves, and though rnoland was unhappy with the decision (because it made his job harder), the linux DRM developers did what they felt was best. You assuming what what good for Linux for a developer, is also good for a BSD developer. As for making rnoland's job harder, it was his choice. Since then, rnoland has made significant progress porting the linux specific changes over to FreeBSD. If you don't believe the changes he's made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm on freedesktop git then you are fooling yourself. Frankly, if I were Robert, I would be offended by that statement you made. I've diffed the code. Suggest that you do the same and see if you can still make the same statements. As has been said time and again, the kernel specific code in mesa/drm serves no purpose other than providing a historical log of the DRM development from that time, so there was no harm in pulling it. The FreeBSD DRM code follows the same development model as the rest of FreeBSD, and I have a hard time believing that such a model doesn't support collaboration. That is certainly an accusation I've never once heard made against the FreeBSD project in recent years till just now. If one stashes his/her development code where few if any can get at it, I don't consider that collaboration. Now, the changes are made, and what's done is done. Can we please just move on? I was going to move along, but I felt your email had so many errors, I couldn't let it got by. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 18:54:31 vehemens wrote: On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: On Sunday 29 November 2009 14:16:13 vehemens wrote: [snip] Your missing the point of using a development structure which supports collobration. [snip] The difference is that you are the only one doing the work now. [snip] Again, your missing the point of using a development structure which supports collobration. [snip] It hasn't moved ... well beyond what was in drm git. If you believe otherwise, your only fooling yourself. [snip] See above comments. Yes, you have made it abundantly clear that you are in favor of having a centralized repository for all DRM development. The fact is, that's not happening now and is not going to happen. That used to be the case, but the linux DRM developers did not see an advantage to that for themselves, and though rnoland was unhappy with the decision (because it made his job harder), the linux DRM developers did what they felt was best. You assuming what what good for Linux for a developer, is also good for a BSD developer. As for making rnoland's job harder, it was his choice. Nice try, but I am making no such assumptions. It was not rnoland's choice to stop having the linux DRM developers stop using a centralized repository for all DRM code. He was quite clearly opposed to it and did not consider it a good choice. Since then, rnoland has made significant progress porting the linux specific changes over to FreeBSD. If you don't believe the changes he's made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm on freedesktop git then you are fooling yourself. Frankly, if I were Robert, I would be offended by that statement you made. I've diffed the code. Suggest that you do the same and see if you can still make the same statements. r6xx/r7xx DRM code, alone, pushes FreeBSD DRM well beyond what was in mesa/drm on freedesktop. As has been said time and again, the kernel specific code in mesa/drm serves no purpose other than providing a historical log of the DRM development from that time, so there was no harm in pulling it. The FreeBSD DRM code follows the same development model as the rest of FreeBSD, and I have a hard time believing that such a model doesn't support collaboration. That is certainly an accusation I've never once heard made against the FreeBSD project in recent years till just now. If one stashes his/her development code where few if any can get at it, I don't consider that collaboration. Many developers have private source repos for their code and only make such code available when it's actually usable for testing or further development by others. Now, the changes are made, and what's done is done. Can we please just move on? I was going to move along, but I felt your email had so many errors, I couldn't let it got by. Nice try baiting me. I've said my two cents worth, and I'm done with this discussion. Adam -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 15:36:51 Adam K Kirchhoff wrote: On Sunday 29 November 2009 18:54:31 vehemens wrote: On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: On Sunday 29 November 2009 14:16:13 vehemens wrote: [snip] Your missing the point of using a development structure which supports collobration. [snip] The difference is that you are the only one doing the work now. [snip] Again, your missing the point of using a development structure which supports collobration. [snip] It hasn't moved ... well beyond what was in drm git. If you believe otherwise, your only fooling yourself. [snip] See above comments. Yes, you have made it abundantly clear that you are in favor of having a centralized repository for all DRM development. The fact is, that's not happening now and is not going to happen. That used to be the case, but the linux DRM developers did not see an advantage to that for themselves, and though rnoland was unhappy with the decision (because it made his job harder), the linux DRM developers did what they felt was best. You assuming what what good for Linux for a developer, is also good for a BSD developer. As for making rnoland's job harder, it was his choice. Nice try, but I am making no such assumptions. It was not rnoland's choice to stop having the linux DRM developers stop using a centralized repository for all DRM code. He was quite clearly opposed to it and did not consider it a good choice. You missing the point as is rnoland. Just because the linux DRM developers stopped using a centralized repository, didn't mean FreeBSD shouldn't as the intial integration work would be still shared reducing the burden on any one person. The approach taken by rnoland however was to shift all the work to himself. Since then, rnoland has made significant progress porting the linux specific changes over to FreeBSD. If you don't believe the changes he's made in the FreeBSD source tree go 'well beyond' what had been in mesa/drm on freedesktop git then you are fooling yourself. Frankly, if I were Robert, I would be offended by that statement you made. I've diffed the code. Suggest that you do the same and see if you can still make the same statements. r6xx/r7xx DRM code, alone, pushes FreeBSD DRM well beyond what was in mesa/drm on freedesktop. As for FreeBSD r6xx/r7xx DRM, here's an email on the subject which is how I remember the events. http://lists.freebsd.org/pipermail/freebsd-x11/2009-February/007624.html -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 29, 2009 at 05:03:51PM -0800, vehemens wrote: You missing the point as is rnoland. Just because the linux DRM developers stopped using a centralized repository, didn't mean FreeBSD shouldn't as the intial integration work would be still shared reducing the burden on any one person. The approach taken by rnoland however was to shift all the work to himself. Is it genuinely necessary to reply to every single mail in this thread, repeating the exact same thing over and over, ad nauseum? pgpsoaYovYUlS.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 29, 2009 at 5:03 PM, vehemens vehem...@verizon.net wrote: On Sunday 29 November 2009 15:36:51 Adam K Kirchhoff wrote: On Sunday 29 November 2009 18:54:31 vehemens wrote: On Sunday 29 November 2009 14:23:44 Adam K Kirchhoff wrote: On Sunday 29 November 2009 14:16:13 vehemens wrote: [snip] Your missing the point of using a development structure which supports collobration. [snip] The difference is that you are the only one doing the work now. [snip] Again, your missing the point of using a development structure which supports collobration. [snip] It hasn't moved ... well beyond what was in drm git. If you believe otherwise, your only fooling yourself. [snip] See above comments. Yes, you have made it abundantly clear that you are in favor of having a centralized repository for all DRM development. The fact is, that's not happening now and is not going to happen. That used to be the case, but the linux DRM developers did not see an advantage to that for themselves, and though rnoland was unhappy with the decision (because it made his job harder), the linux DRM developers did what they felt was best. You assuming what what good for Linux for a developer, is also good for a BSD developer. As for making rnoland's job harder, it was his choice. Nice try, but I am making no such assumptions. It was not rnoland's choice to stop having the linux DRM developers stop using a centralized repository for all DRM code. He was quite clearly opposed to it and did not consider it a good choice. You missing the point as is rnoland. Just because the linux DRM developers stopped using a centralized repository, didn't mean FreeBSD shouldn't as the intial integration work would be still shared reducing the burden on any one person. The approach taken by rnoland however was to shift all the work to himself. Sorry to stick myself into this conversation, but isn't the freebsd tree now your centralized repository? Can't you just clone that and continue as before? -- Dan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-29 at 15:36 -0800, vehemens wrote: I believe that moving away from the current model makes it more difficult to ... spread the burden ..., hence my objections. If you want to call that ranting or complaining, so be it. We no longer get to share the burden with the much larger group of linux devs directly. That *was* my primary objection to reorganizing/abandoning drm git in the first place. Yes, I'm a little bitter about it when I have to recite how we got where we are, but it's done, we lost, move on. As for the FreeBSD code, generally each subsystem has one primary responsible individual. For drm, that person is me. Anyone is more than welcome to submit patches for review by either sending them to the mailing lists, sending them to me, or filing a PR. I've accepted patches from you in the past and I will continue to do so, if you choose to send them. At last check, you had not yet been granted commit privileges for drm git, so your path was still to submit patches to the mailing list, or directly to me. So, I don't quite get how it makes a difference to you if you submit patches based on drm git or against the FreeBSD src tree. For anyone to grant you commit privs, either on fd.o or FreeBSD.org (or most any other repo for that matter) you are going to have to demonstrate a track record of submitting reasonable patches and a willingness to work and get along within that community of developers. It has been more than a year since you submitted anything to me that was coherent and usable. This tar file that you sent me is dated 09/12/09, but despite your arguments, it isn't currently in a form that makes it reasonable to extract the good changes from the bad. I look at diffs pretty much every day. robert. -- Robert Noland rnol...@2hip.net 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sunday 29 November 2009 19:51:55 Robert Noland wrote: On Sun, 2009-11-29 at 15:36 -0800, vehemens wrote: I believe that moving away from the current model makes it more difficult to ... spread the burden ..., hence my objections. If you want to call that ranting or complaining, so be it. We no longer get to share the burden with the much larger group of linux devs directly. That *was* my primary objection to reorganizing/abandoning drm git in the first place. Yes, I'm a little bitter about it when I have to recite how we got where we are, but it's done, we lost, move on. As for the FreeBSD code, generally each subsystem has one primary responsible individual. For drm, that person is me. Anyone is more than welcome to submit patches for review by either sending them to the mailing lists, sending them to me, or filing a PR. I've accepted patches from you in the past and I will continue to do so, if you choose to send them. At last check, you had not yet been granted commit privileges for drm git, so your path was still to submit patches to the mailing list, or directly to me. So, I don't quite get how it makes a difference to you if you submit patches based on drm git or against the FreeBSD src tree. For anyone to grant you commit privs, either on fd.o or FreeBSD.org (or most any other repo for that matter) you are going to have to demonstrate a track record of submitting reasonable patches and a willingness to work and get along within that community of developers. It has been more than a year since you submitted anything to me that was coherent and usable. This tar file that you sent me is dated 09/12/09, but despite your arguments, it isn't currently in a form that makes it reasonable to extract the good changes from the bad. I look at diffs pretty much every day. Robert it no longer matters. I'm going to concide defeat and switch to Linux. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. robert. Suggest that you actually read the emails and IRC comments. Your lack of understanding on the value of the codebase is not in general my problem, except when you impact myself and others as you have done this time. Why bother adding code to a common tree that no operating system has any intention of shipping ever. This simply isn't true. Please don't make statements that are obviously false. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland rnol...@2hip.net 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sat, Nov 28, 2009 at 1:41 PM, Robert Noland rnol...@2hip.net wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: ... I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. That was my understanding of things as well. I wouldn't have dropped the linux-core or bsd-core subdirectories if there was still work going on there. Again, apologies for the build breakage and thanks for having the patience to help work it out. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 28 November 2009 10:41:39 Robert Noland wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. You don't feel sending patches and having integration/testing phases with the tree users use is a good process? shared repos are good, but they do seem to lead to a commit first, review later (if at all) mentality. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 28 November 2009 13:44:53 Dave Airlie wrote: I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. You don't feel sending patches and having integration/testing phases with the tree users use is a good process? shared repos are good, but they do seem to lead to a commit first, review later (if at all) mentality. I think ... that sending patches and having integration/testing phases with the tree users ... is a good process Have to agree that the .. commit first, review later (if at all) mentality. is a bit of problem sometimes. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: On Saturday 28 November 2009 10:41:39 Robert Noland wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. Because unpublished work doesn't exist That goes for the work that I've done that isn't yet published as well. Until it is in the hands of someone besides yourself it is irrelevant. I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. I'm not sure which issue you are referring to right now. But if you mean trying to backport the work of Intel, ATI/AMD and nouveau into a repository that all of the above have now abandoned, none who currently have commit to the drm repo are willing or able to take on that task. Did you miss my plea's, rants and attempts to make valid arguments not to reorganize/abandon drm in the first place? Unfortunately, we lost that battle. It only served to increase the complexity and workload that I am faced with. However, since every major vendor has now pulled out and maintains a private linux repo for their code, the code that lived in drm git was stale, and not terribly useful for anything other than historical purposes. If you are referring to the patches/diffs that you have sent me, then I have always appreciated the work that you have done. The last batch of stuff that you sent me, however was quite a mess. While there was some nice cleanup in it, it also contained at least some reversions of code specifically changed for FreeBSD. Even more of a problem than that was that what you sent me at the time was one big jumble and in no way represented a coherent set of patches that I could apply and commit to any repo. You did state at the time, that it was WIP, so perhaps you have a more coherent patch set now. I should have provided you with direct feedback when you sent me that work and for that I do appologize. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. This is IMHO, the good and bad of git. There is nothing that prevents you from taking your existing drm git and branching it prior to the removal of the code and publishing that on some other server. I would truly hope that it isn't your intent to try to provide an alternate FreeBSD drm build, though there is nothing to prevent it. If you are unwilling or unable to do the work your self, you shouldn't prevent others from doing so. Who would be contributing to this repo besides yourself? And who would be the consumer? For good or bad, the responsibility for drm in FreeBSD lands entirely on my head. I'm happy to review and accept patches based on the
Re: RFC: libdrm repo
On Saturday 28 November 2009 16:21:58 Robert Noland wrote: On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote: On Saturday 28 November 2009 10:41:39 Robert Noland wrote: On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote: On Sunday 22 November 2009 01:01:10 Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. You pissed a number of people off, but the difference with me is that I'm not letting either of you get away with it. There are more then two BSD maintainers, and your statement that neither of them cared is not correct. Don't get me wrong here, I don't like the current state of things, but given current drm development practices, this change was irrelevant. I was a bit frustrated at the build breakage for libdrm, but krh and I worked through that and it is now resolved. While you have provided me with patches in the past, (which are much appreciated) I have not seen consistent or relevant work lately, so it really isn't clear to me how this is a big deal. Given the nature of git, you could just branch your local repo before that commit, though patches based on the old repo are becoming increasingly difficult to merge into real code. I haven't published any of my work recently, but that doesn't mean I haven't done anything that I would like to share. Not sure why you feel this is important however. Because unpublished work doesn't exist That goes for the work that I've done that isn't yet published as well. Until it is in the hands of someone besides yourself it is irrelevant. Thats the whole point of having a public respository. How else can one publish? I gave you a number of suggestions in private emails on how to fix problems such as the merging issue and you were unwilling to take them. I'm not sure which issue you are referring to right now. But if you mean trying to backport the work of Intel, ATI/AMD and nouveau into a repository that all of the above have now abandoned, none who currently have commit to the drm repo are willing or able to take on that task. Did you miss my plea's, rants and attempts to make valid arguments not to reorganize/abandon drm in the first place? Unfortunately, we lost that battle. It only served to increase the complexity and workload that I am faced with. However, since every major vendor has now pulled out and maintains a private linux repo for their code, the code that lived in drm git was stale, and not terribly useful for anything other than historical purposes. First you say abandoning the respository increased your workload, then you say it wasn't useful. Which is it? If you are referring to the patches/diffs that you have sent me, then I have always appreciated the work that you have done. The last batch of stuff that you sent me, however was quite a mess. While there was some nice cleanup in it, it also contained at least some reversions of code specifically changed for FreeBSD. Even more of a problem than that was that what you sent me at the time was one big jumble and in no way represented a coherent set of patches that I could apply and commit to any repo. You did state at the time, that it was WIP, so perhaps you have a more coherent patch set now. I should have provided you with direct feedback when you sent me that work and for that I do appologize. The WIP was sent to you because you had stalled on DRM development and didn't seem to moving forward. I'm surprized that you didn't understand the changes as they were fairly stright forward. The whole point of having a public repository for code is collaboration that it allows. You seem to of lost sight of this goal. This is IMHO, the good and bad of git. There is nothing that prevents you from taking your existing drm git and branching it prior to the
Re: RFC: libdrm repo
On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. I'm probably not the best person to make those change, but I can try to fix that up if nobody else are up for it. thanks, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/23 Michel Dänzer mic...@daenzer.net: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Oh, only radeon_drm.h is in the kernel, so only that should be in include/drm. The other radeon_*.h files live in radeon/. I guess accidentally copied over the userspace headers when I populated the include/drm directory initially. Should be cleaned up now. thanks, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
libdrm headers (Re: RFC: libdrm repo)
On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? -- Pekka Paalanen http://www.iki.fi/pq/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm headers (Re: RFC: libdrm repo)
On Mon, Nov 23, 2009 at 11:50 AM, Pekka Paalanen p...@iki.fi wrote: On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? Yup, as far as I can tell that's what it looked like before my re-org and it's what it finally looks like again. I defnitely agree that it's not an ideal layout, but we can't change it without breaking things. However, now that we use .pc files we should be able to move things around without recent libdrm users breaking. I'm not sure if it's worthwhile though, but if we're moving files around, it's something we can do (mostly) on a per driver basis, but we should of course agree on what kind of layout we want. I'd suggest keeping only kernel header files in include/drm, moving xf86drm.h and xf86drmMode.h to /usr/include/libdrm and moving chipset headers to /usr/include/libdrm/$chipset. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, 2009-11-23 at 11:43 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: 2009/11/23 Michel Dänzer mic...@daenzer.net: On Fri, 2009-11-20 at 17:20 -0500, Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. Is it expected that there are now two slightly different sets of radeon headers in the repo? Which set will get installed? The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Oh, only radeon_drm.h is in the kernel, so only that should be in include/drm. The other radeon_*.h files live in radeon/. I guess accidentally copied over the userspace headers when I populated the include/drm directory initially. Should be cleaned up now. Thanks Kristian. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: libdrm headers (Re: RFC: libdrm repo)
On Mon, 2009-11-23 at 12:13 -0500, Kristian Høgsberg wrote: On Mon, Nov 23, 2009 at 11:50 AM, Pekka Paalanen p...@iki.fi wrote: On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: The headers in include/drm will be installed and libdrm_radeon should be updated to use those headers instead of the ones in radeon/ since they're what's upstream. At least one of the headers in question - radeon_bo.h - isn't in the kernel (and it probably makes no sense to put userland specific headers like that in the kernel) and is outdated in include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? Yup, as far as I can tell that's what it looked like before my re-org and it's what it finally looks like again. I defnitely agree that it's not an ideal layout, but we can't change it without breaking things. However, now that we use .pc files we should be able to move things around without recent libdrm users breaking. I'm not sure if it's worthwhile though, but if we're moving files around, it's something we can do (mostly) on a per driver basis, but we should of course agree on what kind of layout we want. I'd suggest keeping only kernel header files in include/drm, moving xf86drm.h and xf86drmMode.h to /usr/include/libdrm and moving chipset headers to /usr/include/libdrm/$chipset. So, I was completely shocked when I was alerted on irc that libdrm no longer builds on FreeBSD. It appears that you totally whacked drm.h which is a common file shared and installed by all platforms, which has has all of the conditionals ripped from it and now blindly includes only linux bits. I have not yet determined if other such damage has occurred, but any of the includes that came from shared-core and are required for the build or that get installed should not have been mucked with. WTF? robert. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland rnol...@2hip.net 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I don't see how you think choice #2 (the one taken) was the right one. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. Why bother adding code to a common tree that no operating system has any intention of shipping ever. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-22 at 19:01 +1000, Dave Airlie wrote: On Sun, Nov 22, 2009 at 7:10 PM, vehemens vehem...@verizon.net wrote: On Saturday 21 November 2009 20:09:53 Dave Airlie wrote: I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. I already told the both of you that I was planning to use it on IRC, I just haven't had time to put anything in. In addition, he's asking for a repro to libdrm. The way I see it, is there were two choices: 1) repro to libdrm, add the changes, not piss people off 2) add the changes, repro to libdrm, piss people off I think we pissed one person off, not people, as I said, there are two people registered as BSD maintainers for drm code, oga and rnoland, neither of them cared. I'm not sure what value the codebase has if neither Free or OpenBSD are going to use it. Why bother adding code to a common tree that no operating system has any intention of shipping ever. Well, I think that it is safe to say that I really don't like things as they are. Under the circumstances however, the code there is useless and only provided minor historical value. robert. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland rnol...@2hip.net 2Hip Networks -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Friday 20 November 2009 14:20:41 Kristian Høgsberg wrote: 2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. I left the repo as mesa/drm, but I think it makes sense to move it to be a toplevel repo and rename it libdrm. I don't have the admin-fu to that myself so I'll need somebody with those skills to do that for me. I see that you deleted bsd-core dispite the requests of a number of people that you do not. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
I see that you deleted bsd-core dispite the requests of a number of people that you do not. Its git, nobody has touched any of it in ages, and none of the BSD maintainers used it, you can just get it back by branching from the commit before its removal, if you think revival is needed, don't bring back linux-core when you do please. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. I left the repo as mesa/drm, but I think it makes sense to move it to be a toplevel repo and rename it libdrm. I don't have the admin-fu to that myself so I'll need somebody with those skills to do that for me. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tue, Nov 17, 2009 at 18:54:40 +0100, Stephane Marchesin wrote: Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Why would they have to do that? Newer libdrms should stay compatible with older kernels... Cheers, Julien -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tue, 2009-11-17 at 20:54 +0100, Julien Cristau wrote: On Tue, Nov 17, 2009 at 18:54:40 +0100, Stephane Marchesin wrote: Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Why would they have to do that? Newer libdrms should stay compatible with older kernels... And vice-versa. Some people install newer kernels just to have a newer driver for some particular hardware, or a bugfix somewhere. If this breaks 3D, many modern interfaces won't work (these days they are compiz, gnome-shell, or other clutter-based interface). Breaking things by upgrading a kernel is frowned upon on LKML :) Xav -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tuesday 17 November 2009 08:33:30 Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. A number of people have already objected to these changes and have provided good reasons. Please just drop the issue. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Thu, Nov 19, 2009 at 11:54 AM, vehemens vehem...@verizon.net wrote: On Tuesday 17 November 2009 08:33:30 Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. A number of people have already objected to these changes and have provided good reasons. I think Kristian is trying to address those reasons with this proposal. Please stop being an idiot, or at least be a more constructive idiot if you insist on it. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. thanks, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/17 Kristian Høgsberg k...@bitplanet.net: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. For the record, I don't think my concerns were adressed. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/17 Stephane Marchesin marche...@icps.u-strasbg.fr: 2009/11/17 Kristian Høgsberg k...@bitplanet.net: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. For the record, I don't think my concerns were adressed. You're right, of course. However, my libdrm proposal wasn't an attempt to change how we work, it was merely a re-organisation of the drm.git repo to better reflect and support the de facto workflow. Whether we want libdrm in the kernel tree or not is a different discussion from this, as I see it. It may or may not be a good idea, but I'd rather not block this clean up on that discussion ;-) cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
[oops, with reply-all this time] On Tue, Nov 17, 2009 at 18:07, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 9 Nov 2009 17:46:44 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). Btw the kernel releases every 3 months. That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing and we'd hook on to that good testing crowd. Right now libdrm releases are virtually invisible to the OSS people. There's no serious development, no RCs, etc. Since wee can't even pretend to do proper releases, I'd say hook on to the kernel's as those work. I don't see big advantages to packaging it with the kernel, mainly disadvantages. I don't think it'll get wider testing if it's in the kernel, and I don't think compatibility will be easier to maintain. FWIW, you gave me the opposite argument when you decided that DRM development should happen in the kernel. Back then you used to say that we'd get more testers that way. Which one should I believe? There's a big downside too, since it makes packaging much harder. Distros typically stick with one kernel for a relatively long time, but if they want to pick up a libdrm fix unrelated to a new DRM interface (like the one Remi pointed out) they'll have to grab a recent kernel, extract libdrm, and make sure it works with their current kernel (which may involve some extra work if new DRM interfaces have gone in too). Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tue, 17 Nov 2009 18:53:22 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: On Tue, Nov 17, 2009 at 18:07, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 9 Nov 2009 17:46:44 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). Btw the kernel releases every 3 months. That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing and we'd hook on to that good testing crowd. Right now libdrm releases are virtually invisible to the OSS people. There's no serious development, no RCs, etc. Since wee can't even pretend to do proper releases, I'd say hook on to the kernel's as those work. I don't see big advantages to packaging it with the kernel, mainly disadvantages. I don't think it'll get wider testing if it's in the kernel, and I don't think compatibility will be easier to maintain. FWIW, you gave me the opposite argument when you decided that DRM development should happen in the kernel. Back then you used to say that we'd get more testers that way. Which one should I believe? Testers for kernel code, yes. Testers for libdrm code, no. When I install a new kernel I don't typically install new headers and all the other junk that comes with the new kernel, I just install the vmlinuz and make a new initrd if necessary. I don't think I'm alone. But even if we concede that libdrm would get more testers if included in the kernel, there are still other issues to deal with. There's a big downside too, since it makes packaging much harder. Distros typically stick with one kernel for a relatively long time, but if they want to pick up a libdrm fix unrelated to a new DRM interface (like the one Remi pointed out) they'll have to grab a recent kernel, extract libdrm, and make sure it works with their current kernel (which may involve some extra work if new DRM interfaces have gone in too). Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Presumably they'd want the last released version... Anyway I'm just dubious about moving most userland code into the kernel; udev, klibc, etc. I think it makes more things harder than it does easier. But like Kristian said, it's really a separate discussion from making a more standalone libdrm repo. Nothing stops you (or anyone else) from taking that new repo and proposing it for inclusion in the kernel. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
Le 09/11/2009 00:14, Robert Noland a écrit : There are any number of changes that may occur in libdrm that do not impact the KBI and users should be able to get those features/bug fixes without needing a new kernel. Absolutely. In fact, one of the biggest Intel performance wins lately was in a libdrm change [1] that had absolutely nothing to do with the kernel per se. Not having to force a new kernel down our users throat was very welcome. Cheers, Rémi [1] http://cgit.freedesktop.org/mesa/drm/commit/?id=3f3c5be6f908272199ccf53f108b1124bfe0a00e -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, Nov 9, 2009 at 11:51, Rémi Cardona r...@gentoo.org wrote: Le 09/11/2009 00:14, Robert Noland a écrit : There are any number of changes that may occur in libdrm that do not impact the KBI and users should be able to get those features/bug fixes without needing a new kernel. Absolutely. In fact, one of the biggest Intel performance wins lately was in a libdrm change [1] that had absolutely nothing to do with the kernel per se. Not having to force a new kernel down our users throat was very welcome. But then it sees little testing. If you ship together with the kernel, you get the rc test phases and all... Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
Stephane Marchesin wrote: Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? I know BSD OpenSolaris really don't matter much, but there are still some of us using libdrm on kernels other than Linux. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, Nov 9, 2009 at 17:42, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime.People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. I don't care about the transition. I care about the long term. Replace 2.6.32 and 2.6.29 with 2.6.43 and 2.6.40. Where does the 2.6.40 user get his libdrm at that time? Well, once libdrm is with the kernel, you get libdrm ... with the kernel. What's unclear in what I explained? And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime.People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. I don't care about the transition. I care about the long term. Replace 2.6.32 and 2.6.29 with 2.6.43 and 2.6.40. Where does the 2.6.40 user get his libdrm at that time? And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. This is all seeming like a huge pain to avoid cp. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you
Re: RFC: libdrm repo
On Fri, Nov 6, 2009 at 22:23:46 +0100, Jerome Glisse wrote: I think Joe user will install the kernel-header package of its distribution, and libdrm should detect at configure time kernel header version and people should take care to only enable new libdrm stuff when libdrm find the proper header. This imply that we are studious coder and don't forget about that when adding new features needing new headers :) For instance if it detects header with no KMS stuff it should loudly print at end of configure that it disable KMS support. That would lead to a hell of ifdefs in libdrm. I think keeping copies of the latest kernel drm headers in the libdrm repo and tarballs would be best. Cheers, Julien -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. This is why I've also argued against having libdrm not install the ioctl headers. It seems like the argument is mostly that having libdrm keep a copy of the kernel headers in the repo is bad because people might cp the file wrong. If the cost of not keeping them in the repo is having the libdrm and its consumers be ifdef hell, I will keep a cp in the repo. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. This is why I've also argued against having libdrm not install the ioctl headers. It seems like the argument is mostly that having libdrm keep a copy of the kernel headers in the repo is bad because people might cp the file wrong. If the cost of not keeping them in the repo is having the libdrm and its consumers be ifdef hell, I will keep a cp in the repo. Now I don't get it. You say versioning libdrm headers is the right thing? Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime. People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. If the only reason not to merge the libdrm into the kernel tree is because you have a difficult time finding a libdrm for old kernels (and only during the transition), well I'd say that means there's no real problem here. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime. People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. If the only reason not to merge the libdrm into the kernel tree is because you have a difficult time finding a libdrm for old kernels (and only during the transition), well I'd say that means there's no real problem here. There are any number of changes that may occur in libdrm that do not impact the KBI and users should be able to get those features/bug fixes without needing a new kernel. robert. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___
Re: RFC: libdrm repo
Hi, the broweseable libdrm GIT repository has a little typo: http://cgit.freedesktop.org/~krh/libdrm (not libdrm.git) Kind Regards, - Sedat - [1] http://marc.info/?l=dri-develm=125753272918892w=2 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
