Re: Mesa 8.0 Info
On Monday 13 February 2012 13:57:12 Pietro Cerutti wrote: On 2012-Feb-13, 00:34, vehemens wrote: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce3 8e1c9c163ed2b91bc FWIW, I'm going to update graphics/libosmesa within the next few days. A long as you account for removed changes such as 300c, r600c: Remove these DRI drivers., you should be fine. http://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/drivers/dri?id=de22b9018f2516a3948d920c6bb1ffe659d7f230 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Mesa 8.0 Info
http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates
The following reply was made to PR kern/150514; it has been noted by GNATS. From: vehemens vehem...@verizon.net To: bug-follo...@freebsd.org, vehem...@verizon.net Cc: Subject: Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates Date: Tue, 08 Mar 2011 02:37:18 -0800 Ping. Same question as before. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates
The following reply was made to PR kern/150514; it has been noted by GNATS. From: vehemens vehem...@verizon.net To: bug-follo...@freebsd.org, vehem...@verizon.net Cc: Subject: Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates Date: Tue, 22 Feb 2011 22:56:57 -0800 Could you tell me why this pr is suspended? ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates
The following reply was made to PR kern/150514; it has been noted by GNATS. From: vehemens vehem...@verizon.net To: bug-follo...@freebsd.org, vehem...@verizon.net Cc: Subject: Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates Date: Wed, 17 Nov 2010 23:00:21 -0800 I submitted the patches, but they were identified as likely spam and has been quarantined. Please pull them from the quarantine. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
kern/152354: Obsolete Files
Number: 152354 Category: kern Synopsis: Obsolete Files Confidential: no Severity: non-critical Priority: low Responsible:freebsd-bugs State: open Quarter: Keywords: Date-Required: Class: change-request Submitter-Id: current-users Arrival-Date: Thu Nov 18 07:30:14 UTC 2010 Closed-Date: Last-Modified: Originator: vehemens Release:current Organization: Environment: Description: The following files are no longer used and should be removed: src/sys/dev/drm/drm-preprocess.sh src/sys/dev/drm/drm-subprocess.pl How-To-Repeat: Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates
The following reply was made to PR kern/150514; it has been noted by GNATS. From: vehemens vehem...@verizon.net To: bug-follo...@freebsd.org, vehem...@verizon.net Cc: Subject: Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates Date: Sun, 31 Oct 2010 03:41:08 -0700 Given that the change consists mainly of file moves, what format would you like the patch in? ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
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
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: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 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 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 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
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 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
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 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
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
pixman_region_copy problem
Anbody else seeing this pixman problem? Assertion failed: (PREFIX(_selfcheck) (src)), function pixman_region_copy, file pixman-region.c, line 373. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
usb/135542: boot loader does not work with a usb keyboard
Number: 135542 Category: usb Synopsis: boot loader does not work with a usb keyboard Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Sat Jun 13 09:30:02 UTC 2009 Closed-Date: Last-Modified: Originator: vehemens Release:7.2 stable Organization: Environment: FreeBSD fred.dsl-verizon.net 7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Jun 13 00:49:51 PDT 2009 vehem...@fred.dsl-verizon.net:/usr/obj/usr/src/sys/FRED amd64 Description: On two different machines (both ASUS M2A-VM), I'm unable to configure the system to use a USB keyboard and have the boot loader respond to keyboard input. If I enable USB legacy support, the kernel panics with a ohci_add_done. If I disable USB legacy support, the boot loader will not respond to keyboard input. How-To-Repeat: Fix: Release-Note: Audit-Trail: Unformatted: ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: What do ASCII codes 128-159 stand for?
Ever wonder where we would be as a civilization if the additional codes had been used for math symbols and greek letters as used in engineering and science. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
svn commit: r190595 - head/sys/dev/drm
Author: rnoland Date: Tue Mar 31 17:52:05 2009 New Revision: 190595 URL: http://svn.freebsd.org/changeset/base/190595 Log: Simplify the radeon microcode loading. Submitted by: Christoph Mallon MFC after:3 days Modified: head/sys/dev/drm/r600_cp.c head/sys/dev/drm/radeon_cp.c I don't see the point of this change given that you are deveating from a code base which makes incorporating future code changes that much more diffcult. Could you back this one out? ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r190595 - head/sys/dev/drm
On Thursday 02 April 2009 12:25:52 am Robert Noland wrote: On Wed, 2009-04-01 at 23:24 -0700, vehemens wrote: Author: rnoland Date: Tue Mar 31 17:52:05 2009 New Revision: 190595 URL: http://svn.freebsd.org/changeset/base/190595 Log: Simplify the radeon microcode loading. Submitted by: Christoph Mallon MFC after:3 days Modified: head/sys/dev/drm/r600_cp.c head/sys/dev/drm/radeon_cp.c I don't see the point of this change given that you are deveating from a code base which makes incorporating future code changes that much more diffcult. There are no future code changes to be gotten from git... What are your plans to incoporate DRI2 and KMS into FreeBSD then? Could you back this one out? Nope, I showed it to alex before I committed it and he is planning to send it up in linux as well. git is unfortunately a wasteland, even the nouveau guys are preparing to move out... It is still much easier for me to work with Alex and the nouveau folks than Intel though... If you mean http://cgit.freedesktop.org/mesa/drm/ then I would agree, but the why appears to me to be a result of Linux developers interfering with those that would contribute to BSD. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: drm: Branch 'r6xx-r7xx-support' - 117 commits
On Sunday 29 March 2009 10:55:52 pm Alex Deucher wrote: New commits: commit c3c2ae466cfa1d4e079f6f0396e8f0f68ecb84b8 Merge: 48b5f09... e2d7dfb... Author: Alex Deucher alexdeuc...@gmail.com Date: Mon Mar 30 01:54:54 2009 -0400 Merge branch 'master' into r6xx-r7xx-support thank you -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: changes to upstreaming process for Linux code.
On Saturday 28 February 2009 09:06:38 am Robert C. Noland III wrote: On Fri, 2009-02-27 at 23:54 -0800, vehemens wrote: On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote: On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie airl...@linux.ie wrote: Prompted by how well it worked with Intel, and changes in my personal life leading to reduced time availability (except at 4am...) I'm going to clarify the process for getting patches upstream now. (a...@amd also trialed this to get r600 upstream). 1. Apart from maybe minor changes I will no longer pull drm.git patches into Linux kernel tree automatically. 2. All patches should be sent to dri-devel and me against my drm-next tree. 3. Patches must conform to kernel coding standards and have acceptable checkpatch.pl results. My only major issues with checkpatch.pl is 80 char line length restrictions, please try your best but don't make the code really ugly to achieve this. Some scripts/people are too anal. This also means no kernel version checks upstream (however we might be able to convince people about this, if we get build from Linus tree working). 4. I will accept sub-module maintainers who want to maintain their driver in a git tree, but it'll take a bit of time for me to trust you that I'll pull directly, and patches should still pass by the list. Ask Eric how to do this. 5. if someone wants to step up and maintain drm.git as a going concern let me know, I'm glad to help if I can. Sounds good to me - one question: should we divorce libdrm from the drm.git repo? As long as it stays on xorg, I wouldn't object as it would allow drm.git master to be used for leading edge development. Not really, As long as people are allowed to bypass drm git and make infrastructure changes, it means that in order for anyone else to try and work in drm git, they have to do the work of back-porting other peoples work before they can do their own work. There needs to be a central point for drm development and that point is not Linus' tree. robert. People have always been free to bypass drm.git, and have been doing it for a number of years. The general consensus is to merge the different branches back into one place, that being drm.git. I don't see that happening while the offical repository of libdrm is in drm.git as there would always be objections to changes that weren't main-stream. cheers, Kristian --- --- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - - Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: changes to upstreaming process for Linux code.
On Saturday 28 February 2009 05:28:38 am Pekka Paalanen wrote: On Fri, 27 Feb 2009 23:54:21 -0800 vehemens vehem...@verizon.net wrote: On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote: On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie airl...@linux.ie wrote: Prompted by how well it worked with Intel, and changes in my personal life leading to reduced time availability (except at 4am...) I'm going to clarify the process for getting patches upstream now. (a...@amd also trialed this to get r600 upstream). 1. Apart from maybe minor changes I will no longer pull drm.git patches into Linux kernel tree automatically. 2. All patches should be sent to dri-devel and me against my drm-next tree. 3. Patches must conform to kernel coding standards and have acceptable checkpatch.pl results. My only major issues with checkpatch.pl is 80 char line length restrictions, please try your best but don't make the code really ugly to achieve this. Some scripts/people are too anal. This also means no kernel version checks upstream (however we might be able to convince people about this, if we get build from Linus tree working). 4. I will accept sub-module maintainers who want to maintain their driver in a git tree, but it'll take a bit of time for me to trust you that I'll pull directly, and patches should still pass by the list. Ask Eric how to do this. 5. if someone wants to step up and maintain drm.git as a going concern let me know, I'm glad to help if I can. Sounds good to me - one question: should we divorce libdrm from the drm.git repo? As long as it stays on xorg, I wouldn't object as it would allow drm.git master to be used for leading edge development. Leading edge development of what, exactly? If libdrm is moved out of drm.git, what is left is... Nouveau DRM? Poor wording on my part. What I (and others) would like see to happen is the various branches merged into master. Having everything centralized should improve the code quality as improvements would be pooled. What does this suggestion of divorce libdrm mean? Only libdrm itself, or all the libdrm_* additional libraries too? To a single other repo, or each (sub-)library to its own repo? The intent here would be to remove any possible objection of merging the branches into master. If this is proves sucessful, the fork would die off at some point. btw. where is Radeon DRM development happening now and in the near future? Do you need drm.git linux-core for anything? Any development that occurs, doesn't show up in drm.git until someone decides to share it. How and when that occurs is up to the individual. The only solution I know of is to have a project that the developer wants to contribute to. Having multiple branches in one place would result in drm.git being much more useful then it currently is. This would include linux-core. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: changes to upstreaming process for Linux code.
On Friday 27 February 2009 01:40:25 pm Dave Airlie wrote: Prompted by how well it worked with Intel, and changes in my personal life leading to reduced time availability (except at 4am...) I'm going to clarify the process for getting patches upstream now. (a...@amd also trialed this to get r600 upstream). 1. Apart from maybe minor changes I will no longer pull drm.git patches into Linux kernel tree automatically. 2. All patches should be sent to dri-devel and me against my drm-next tree. 3. Patches must conform to kernel coding standards and have acceptable checkpatch.pl results. My only major issues with checkpatch.pl is 80 char line length restrictions, please try your best but don't make the code really ugly to achieve this. Some scripts/people are too anal. This also means no kernel version checks upstream (however we might be able to convince people about this, if we get build from Linus tree working). 4. I will accept sub-module maintainers who want to maintain their driver in a git tree, but it'll take a bit of time for me to trust you that I'll pull directly, and patches should still pass by the list. Ask Eric how to do this. 5. if someone wants to step up and maintain drm.git as a going concern let me know, I'm glad to help if I can. I would be interested, but I have been unable to get a commit bit for 6 months. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: changes to upstreaming process for Linux code.
On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote: On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie airl...@linux.ie wrote: Prompted by how well it worked with Intel, and changes in my personal life leading to reduced time availability (except at 4am...) I'm going to clarify the process for getting patches upstream now. (a...@amd also trialed this to get r600 upstream). 1. Apart from maybe minor changes I will no longer pull drm.git patches into Linux kernel tree automatically. 2. All patches should be sent to dri-devel and me against my drm-next tree. 3. Patches must conform to kernel coding standards and have acceptable checkpatch.pl results. My only major issues with checkpatch.pl is 80 char line length restrictions, please try your best but don't make the code really ugly to achieve this. Some scripts/people are too anal. This also means no kernel version checks upstream (however we might be able to convince people about this, if we get build from Linus tree working). 4. I will accept sub-module maintainers who want to maintain their driver in a git tree, but it'll take a bit of time for me to trust you that I'll pull directly, and patches should still pass by the list. Ask Eric how to do this. 5. if someone wants to step up and maintain drm.git as a going concern let me know, I'm glad to help if I can. Sounds good to me - one question: should we divorce libdrm from the drm.git repo? As long as it stays on xorg, I wouldn't object as it would allow drm.git master to be used for leading edge development. cheers, Kristian --- --- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
next release of xineramaproto
Given that last years changes to xineramaproto appear to impact a number of applications (on my system anyway), could anyone tell me when the next release of xineramaproto will occur? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 1/2] Remove Intel drivers from linux-core
On Tuesday 17 February 2009 05:43:32 pm Robert C. Noland III wrote: On Mon, 2009-02-16 at 18:39 +, Owain Ainsworth wrote: On Sat, Feb 14, 2009 at 11:24:18PM +0200, Pekka Paalanen wrote: From 29d3f6e9c1258736c3199834b293b8128faef2ad Mon Sep 17 00:00:00 2001 From: Pekka Paalanen p...@iki.fi Date: Sat, 14 Feb 2009 21:49:08 +0200 Subject: [PATCH] Remove Intel drivers from linux-core Both i810 and i915 DRM Linux kernel specific sources are removed. Intel developers have stated, that their DRM development continues elsewhere in some Linux kernel trees. This makes the code in drm.git just dead weight. This removal allows further cleanup of compatibility code. shared-core and bsd-core are left untouched. Personally i'd also kill bsd-core, since it's outdates and contains so much shit we don't want. Then again Robert may have something to say bout this. I still have code against it... I'm not sure what I'm going to do about it though How about incorporating my patches while I continue to attempt to obtain a commit account:? robert. -0- -- who is still slacking on getting a fd.o account. -- Robert C. Noland III rnol...@2hip.net 2 Hip Networks -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Unhappy Xorg upgrade
On Saturday 31 January 2009 04:20:26 pm Alex Goncharov wrote: ,--- You/vehemens (Sat, 31 Jan 2009 13:54:42 -0800) * | On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote: | So, a *fundamental* (practically an OS component) port is brought in | -- and it disables my system. What is my way of action? Right -- | install the old packages, taken from an FTP site (is there a way to | get the previous source, that is all the ports/*/*/Makefile files? | Csup can only go forward -- or can it go back?) | | You ignored the first part of the email which is that the ports | system is flawed due to the lack of a stable versus current branch. The FreeBSD model as what it is and I, for one, prefer it to Linux distros' models. In other words what you call a flaw, I call a virtue. Your missing the point. This has nothing to do with Linux. The issue is that that while src has a stable versus current branch, there is no stable branch for ports. The result is major updates are almost always problematic. | It seems to me that you want to run a stable branch, while the ports | tree is effectively a current branch. If somebody tells me that running the new X on my computers will be better if I switch the base system from STABLE to CURRENT, I'll do it in a heartbeat. (In fact one of my other systems does run CURRENT, only I never installed X there -- I don't use that system as a front end.) The issue is with the ports approach, not the base system (aka src) approach. See above comments. | When I install the old packages, I can no longer rebuild and install | new (say `csup'ed on 2009-03-01) port components, as one whole -- I | can only do it selectively, excluding from the upgrade most | X-dependent things. That sucks and will lead to a problem earlier or | later. | | I never update /usr/ports directly. I have a separate csup ports | area. When I update, I save the old ports tree and replace it with | a new one. If a problem occurs, I can fall back to the old tree or | pieces of it. An interesting model -- but how would you be better off falling back to the old ports tree in case of a bad (for you) new X? Yes, you could rebuild and return to using the old X. Then what? Would you be able to keep up with ports upgrades. You wouldn't be able to keep other updates unless you manully patched the tree, but you would be able to use the system until it's fixed. You may assume that X is going to be fixed -- but what if not, in, say a year? Your kidding me right?? | Well, it depends on which ports you are updating. All. Your saying that you build every port including the language options and never had a problem in the last 18 months until the xorg update ?!?!? | If you only run X, then I would expect your statement to be correct. Not sure what you mean here: nobody runs only X. It's impossible. To be precise, it's the xorg port. So yes it's possible. | | And last, many of the video drivers have little if any support. If | | you have something other then ati/intel/nivdia, you should expect | | problems. Input drivers are in a similar state. | | Both my systems I've been reporting problems with are using the `nv' | driver: | |$ grep /modules/drivers /var/log/Xorg.0.log |(II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so | | One system (Dell Latitude) could not be made operational with the new | X at all; the other has garbage in the windows and the captive mouse | pointer -- both issues new in the new X. | | See above :) Which point? :-) All of them. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
On Sunday 01 February 2009 11:22:52 am Alex Goncharov wrote: | This has nothing to do with Linux. The issue is that that while src | has a stable versus current branch, there is no stable branch for | ports. The result is major updates are almost always problematic. Any data points to support the last statement? How about the last two xorg updates. Gnome has similar problems. | You wouldn't be able to keep other updates unless you manully patched the | tree, but you would be able to use the system until it's fixed. What the ETA for the new X fix? Not a clue. | You may assume that X is going to be fixed -- but what if not, in, say | a year? | | Your kidding me right?? No. You *know* that it is going to be fixed in a year? If yes, what's the source of your knowledge? What resources are going to be dedicated to work on my three problems? Not a clue. | | Well, it depends on which ports you are updating. | | All. | | Your saying that you build every port including the language options and | never had a problem in the last 18 months until the xorg update ?!?!? Yes, I am saying exactly this. I happen not to run Gnome or KDE. | | If you only run X, then I would expect your statement to be correct. | | Not sure what you mean here: nobody runs only X. It's impossible. | | To be precise, it's the xorg port. So yes it's possible. Hm, let's see: Information for xorg-server-1.5.3_2,1: Depends on: ([ I exclude the X things ]): Dependency: expat-2.0.1 Dependency: openssl-0.9.8j Dependency: pciids-20081012 Dependency: e2fsprogs-libuuid-1.41.3_1 Dependency: python25-2.5.2_3 Dependency: pkg-config-0.23_1 Dependency: libpthread-stubs-0.1 Dependency: libiconv-1.11_1 Dependency: gettext-0.17_1 Plenty of non-xorg things are needed for xorg, right? And if I build from the sources, I also need gmake, bison, autoconf etc. Your kidding me again right?? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
On Fri Jan 30 11:53:16 PST 2009, Peter Jeremy wrote: As a general note, this is the second time in a row that an X.org upgrade broke X for a significant number of people. IMO, this suggests that our approach to X.org upgrades needs significant changes (see below). X11 is a critical component for anyone who is using FreeBSD as a desktop and having upgrades fail or come with significant POLA violations and regressions for significant numbers of people is not acceptable. The problem isn't so much as a problem with xorg updates as it is with the overall port approach. Not having a stable versus current ports approach is probably the biggest cause of the problems seen here. The port freezes don't help either. In general when upgrading, you take your chances. If a port upgrade fails, you should fall back to what worked. Trying to partial rebuild ports versus rebuilding from scratch after a major update is just asking for problems. There probably needs to be a more incremental approach when upgrading major ports. For example, I updated my system a piece at a time over the last several months, and had no significant problems with the offical x11 upgrade as the changes were small. And last, many of the video drivers have little if any support. If you have something other then ati/intel/nivdia, you should expect problems. Input drivers are in a similar state. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote: ,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) * | In general when upgrading, you take your chances. If a port upgrade | fails, you should fall back to what worked. So, a *fundamental* (practically an OS component) port is brought in -- and it disables my system. What is my way of action? Right -- install the old packages, taken from an FTP site (is there a way to get the previous source, that is all the ports/*/*/Makefile files? Csup can only go forward -- or can it go back?) You ignored the first part of the email which is that the ports system is flawed due to the lack of a stable versus current branch. It seems to me that you want to run a stable branch, while the ports tree is effectively a current branch. When I install the old packages, I can no longer rebuild and install new (say `csup'ed on 2009-03-01) port components, as one whole -- I can only do it selectively, excluding from the upgrade most X-dependent things. That sucks and will lead to a problem earlier or later. I never update /usr/ports directly. I have a separate csup ports area. When I update, I save the old ports tree and replace it with a new one. If a problem occurs, I can fall back to the old tree or pieces of it. | Trying to partial rebuild ports versus rebuilding from scratch after | a major update is just asking for problems. Exactly -- but I haven't done this -- and I have big problems with the new X. | There probably needs to be a more incremental approach when | upgrading major ports. For example, I updated my system a piece at | a time over the last several months, and had no significant problems | with the offical x11 upgrade as the changes were small. I've been rebuilding and reinstalling ports every weekend, for about 1.5 years -- with no problem until the last one, when the new X was in. Well, it depends on which ports you are updating. If you only run X, then I would expect your statement to be correct. | And last, many of the video drivers have little if any support. If | you have something other then ati/intel/nivdia, you should expect | problems. Input drivers are in a similar state. Both my systems I've been reporting problems with are using the `nv' driver: $ grep /modules/drivers /var/log/Xorg.0.log (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so One system (Dell Latitude) could not be made operational with the new X at all; the other has garbage in the windows and the captive mouse pointer -- both issues new in the new X. See above :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
On Fri Jan 30 11:53:16 PST 2009, Peter Jeremy wrote: As a general note, this is the second time in a row that an X.org upgrade broke X for a significant number of people. IMO, this suggests that our approach to X.org upgrades needs significant changes (see below). X11 is a critical component for anyone who is using FreeBSD as a desktop and having upgrades fail or come with significant POLA violations and regressions for significant numbers of people is not acceptable. The problem isn't so much as a problem with xorg updates as it is with the overall port approach. Not having a stable versus current ports approach is probably the biggest cause of the problems seen here. The port freezes don't help either. In general when upgrading, you take your chances. If a port upgrade fails, you should fall back to what worked. Trying to partial rebuild ports versus rebuilding from scratch after a major update is just asking for problems. There probably needs to be a more incremental approach when upgrading major ports. For example, I updated my system a piece at a time over the last several months, and had no significant problems with the offical x11 upgrade as the changes were small. And last, many of the video drivers have little if any support. If you have something other then ati/intel/nivdia, you should expect problems. Input drivers are in a similar state. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Unhappy Xorg upgrade
On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote: ,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) * | In general when upgrading, you take your chances. If a port upgrade | fails, you should fall back to what worked. So, a *fundamental* (practically an OS component) port is brought in -- and it disables my system. What is my way of action? Right -- install the old packages, taken from an FTP site (is there a way to get the previous source, that is all the ports/*/*/Makefile files? Csup can only go forward -- or can it go back?) You ignored the first part of the email which is that the ports system is flawed due to the lack of a stable versus current branch. It seems to me that you want to run a stable branch, while the ports tree is effectively a current branch. When I install the old packages, I can no longer rebuild and install new (say `csup'ed on 2009-03-01) port components, as one whole -- I can only do it selectively, excluding from the upgrade most X-dependent things. That sucks and will lead to a problem earlier or later. I never update /usr/ports directly. I have a separate csup ports area. When I update, I save the old ports tree and replace it with a new one. If a problem occurs, I can fall back to the old tree or pieces of it. | Trying to partial rebuild ports versus rebuilding from scratch after | a major update is just asking for problems. Exactly -- but I haven't done this -- and I have big problems with the new X. | There probably needs to be a more incremental approach when | upgrading major ports. For example, I updated my system a piece at | a time over the last several months, and had no significant problems | with the offical x11 upgrade as the changes were small. I've been rebuilding and reinstalling ports every weekend, for about 1.5 years -- with no problem until the last one, when the new X was in. Well, it depends on which ports you are updating. If you only run X, then I would expect your statement to be correct. | And last, many of the video drivers have little if any support. If | you have something other then ati/intel/nivdia, you should expect | problems. Input drivers are in a similar state. Both my systems I've been reporting problems with are using the `nv' driver: $ grep /modules/drivers /var/log/Xorg.0.log (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so One system (Dell Latitude) could not be made operational with the new X at all; the other has garbage in the windows and the captive mouse pointer -- both issues new in the new X. See above :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS UP] drm merged to -STABLE
On Saturday 10 January 2009 08:49:01 am Robert Noland wrote: On Sat, 2009-01-10 at 10:01 -0500, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below - Support AMD/ATI IGP based chips (rs690/rs485) - Lots of code cleanups - Lots of other fixes and changes since the existing drm is 2+ years old If you are experiencing a garbled screen with certain pci/pci-e based radeons, I have another patch in HEAD that isn't included yet. I decided to go ahead and fully sync to HEAD, so this should be resolved as well. This added: - Use bus_dma to allocate scatter/gather pages for pci GART. This fixes garbled screen issues on pci based radeons. - Prevent drm from attaching to secondary devices even if they have the the same pci id. What's your plan on incorporating r6xx/r7xx drm :? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: xserver distribution missing sdksyms.sh
On Monday 05 January 2009 11:03:55 pm Paulo César Pereira de Andrade wrote: vehemens wrote: subject says it all Thanks. I feel dumb for this one :-) Last time I run make distcheck was like one month ago, when I added DISTCLEANFILES = doltcompile doltlibtool to the toplevel Makefile.am I always build using tar balls, and I wait about a month before mentioning this type of problem : ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Mesa3d-dev] dri_sarea.h still in tarball list
On Tuesday 06 January 2009 06:36:39 am Brian Paul wrote: vehemens wrote: dri_sarea.h was removed, but the Makefile reference is still present. Fixed. -Brian thanks -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] dri_sarea.h still in tarball list
dri_sarea.h was removed, but the Makefile reference is still present. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
xserver distribution missing sdksyms.sh
subject says it all ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: drm: Branch 'master'
On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote: ... New commits: commit 9583c099b4a08b49e03f7b461c344b6d277fd262 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Wed Dec 10 15:47:28 2008 -0800 Revert Merge branch 'modesetting-gem' This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208. We really just want the libdrm and ioctl bits, not all the driver stuff. ... Could you help me out and explain why we don't want the merge? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Thursday 11 December 2008 04:28:48 pm Jesse Barnes wrote: On Thursday, December 11, 2008 4:16 pm vehemens wrote: On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote: ... New commits: commit 9583c099b4a08b49e03f7b461c344b6d277fd262 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Wed Dec 10 15:47:28 2008 -0800 Revert Merge branch 'modesetting-gem' This reverts commit 6656db10551bbb8770dd945b6d81d5138521f208. We really just want the libdrm and ioctl bits, not all the driver stuff. ... Could you help me out and explain why we don't want the merge? Because it pulled in a bunch of driver code that probably isn't ready (at least I didn't want to merge it w/o acks from Dave, Jerome and Stephane). I just posted a more minimal patch earlier today. I can understand not merging code when it's not ready, but that begs the question on who would be affected at this point given the way most distributions are handled :? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Missing libX11 Headers
Need to add big5hkscs.h and gbk.h to the distribution list. reference commit: 2008-11-22 18:40:54 (GMT) 67e34d7a82ccd31f1208c0c43a6d58c3c05bf51 Added remaining xlib patch required for gb18030 support (#1573). --- libX11/src/xlibi18n/Makefile.am.org 2007-10-27 23:11:49.0 -0700 +++ libX11/src/xlibi18n/Makefile.am 2008-11-28 17:35:26.0 -0800 @@ -91,11 +91,13 @@ lcUniConv/ascii.h\ lcUniConv/big5.h\ lcUniConv/big5_emacs.h\ + lcUniConv/big5hkscs.h\ lcUniConv/cp1133.h\ lcUniConv/cp1251.h\ lcUniConv/cp1255.h\ lcUniConv/cp1256.h\ lcUniConv/gb2312.h\ + lcUniConv/gbk.h\ lcUniConv/georgian_academy.h\ lcUniConv/georgian_ps.h\ lcUniConv/iso8859_1.h\ --- libX11/src/xlibi18n/Makefile.am.org 2007-10-27 23:11:49.0 -0700 +++ libX11/src/xlibi18n/Makefile.am 2008-11-28 17:35:26.0 -0800 @@ -91,11 +91,13 @@ lcUniConv/ascii.h\ lcUniConv/big5.h\ lcUniConv/big5_emacs.h\ + lcUniConv/big5hkscs.h\ lcUniConv/cp1133.h\ lcUniConv/cp1251.h\ lcUniConv/cp1255.h\ lcUniConv/cp1256.h\ lcUniConv/gb2312.h\ + lcUniConv/gbk.h\ lcUniConv/georgian_academy.h\ lcUniConv/georgian_ps.h\ lcUniConv/iso8859_1.h\ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Wednesday 03 December 2008 09:21:51 pm Peter Hutterer wrote: On Wed, Dec 03, 2008 at 08:08:35PM -0800, vehemens wrote: On Wednesday 03 December 2008 02:33:34 pm Peter Hutterer wrote: http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html That's a quick brain dump of input related things I could think of that are repeatedly asked on the list, irc, and bugreports. The information is accurate as of git master today and extends to server 1.5 (mostly) and server 1.6. Hate to be a bringer of bad news but The evdev driver is the preferred input driver. If you are not running Linux, then evdev is not available for you and you can keep using the mouse/kbd drivers. is not correct. the statement is correct. If the keyboard driver doesn't work, please file a bug at bugs.freedesktop.org. Actually that's two statements and the blog doesn't list the first one. I filed a bug so you can correct your blog : By the way, what type of testing are you doing? OS/kernel version(s)? 32 bit and/or 64 bit? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
On Wednesday 03 December 2008 02:33:34 pm Peter Hutterer wrote: http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html That's a quick brain dump of input related things I could think of that are repeatedly asked on the list, irc, and bugreports. The information is accurate as of git master today and extends to server 1.5 (mostly) and server 1.6. Hate to be a bringer of bad news but The evdev driver is the preferred input driver. If you are not running Linux, then evdev is not available for you and you can keep using the mouse/kbd drivers. is not correct. It faults with git master on my FreeBSD machine. (II) XINPUT: Adding extended input device Mouse0 (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) filter chain progression: 2.00 (**) Mouse0: (accel) filter stage 0: 20.00 ms (**) Mouse0: (accel) set acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (**) Option CoreKeyboard (**) Keyboard0: always reports core events (**) Option Protocol standard (**) Keyboard0: Protocol: standard (**) Option AutoRepeat 500 30 (**) Option XkbRules xorg (**) Keyboard0: XkbRules: xorg (**) Option XkbModel pc105 (**) Keyboard0: XkbModel: pc105 (**) Option XkbLayout us (**) Keyboard0: XkbLayout: us (**) Option CustomKeycodes off (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD) Fatal server error: Caught signal 11. Server aborting ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
drm vblank memory allocation
Would anyone object to using a struct for the vblank crtc data to eliminate
the multiple allocs / frees?
For example:
struct drm_vblank {
wait_queue_head_t vbl_queue;
atomic_t _vblank_count;
struct drm_vbl_sig_list vbl_sigs;
atomic_t vblank_refcount;
u32 last_vblank;
int vblank_enabled;
u32 vblank_premodeset;
u32 vblank_suspend;
};
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
misc drm patches
Here are a few drm patches.
correct another lock leak.
add missing link.
negate return value. minor cleanup while we are here.
diff --git a/bsd-core/drm_bufs.c b/bsd-core/drm_bufs.c
index 3508331..c793634 100644
--- a/bsd-core/drm_bufs.c
+++ b/bsd-core/drm_bufs.c
@@ -832,12 +832,12 @@ int drm_addbufs_sg(struct drm_device *dev, drm_buf_desc_t *request)
if (request-count 0 || request-count 4096)
return EINVAL;
- DRM_SPINLOCK(dev-dma_lock);
-
order = drm_order(request-size);
if (order DRM_MIN_ORDER || order DRM_MAX_ORDER)
return EINVAL;
+ DRM_SPINLOCK(dev-dma_lock);
+
/* No more allocations after first buffer-using ioctl. */
if (dev-buf_use != 0) {
DRM_SPINUNLOCK(dev-dma_lock);
diff --git a/bsd-core/radeon_microcode.h b/bsd-core/radeon_microcode.h
new file mode 12
index 000..709fff3
--- /dev/null
+++ b/bsd-core/radeon_microcode.h
@@ -0,0 +1 @@
+../shared-core/radeon_microcode.h
\ No newline at end of file
diff --git a/shared-core/radeon_irq.c b/shared-core/radeon_irq.c
index d21761f..0844c0b 100644
--- a/shared-core/radeon_irq.c
+++ b/shared-core/radeon_irq.c
@@ -74,7 +74,7 @@ int radeon_enable_vblank(struct drm_device *dev, int crtc)
default:
DRM_ERROR(tried to enable vblank on non-existent crtc %d\n,
crtc);
- return EINVAL;
+ return -EINVAL;
}
} else {
switch (crtc) {
@@ -87,7 +87,7 @@ int radeon_enable_vblank(struct drm_device *dev, int crtc)
default:
DRM_ERROR(tried to enable vblank on non-existent crtc %d\n,
crtc);
- return EINVAL;
+ return -EINVAL;
}
}
@@ -279,9 +279,8 @@ u32 radeon_get_vblank_counter(struct drm_device *dev, int crtc)
} else if (crtc == 1) {
crtc_cnt_reg = RADEON_CRTC2_CRNT_FRAME;
crtc_status_reg = RADEON_CRTC2_STATUS;
- } else {
+ } else
return -EINVAL;
- }
return RADEON_READ(crtc_cnt_reg) + (RADEON_READ(crtc_status_reg) 1);
}
}
@@ -372,9 +371,9 @@ void radeon_driver_irq_uninstall(struct drm_device * dev)
dev_priv-irq_enabled = 0;
+ /* Disable *all* interrupts */
if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_RS690)
RADEON_WRITE(R500_DxMODE_INT_MASK, 0);
- /* Disable *all* interrupts */
RADEON_WRITE(RADEON_GEN_INT_CNTL, 0);
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: misc drm patches
On Wednesday 28 May 2008 04:35:42 am Oleg Nauman wrote: On Wed, May 28, 2008 at 10:34 AM, vehemens [EMAIL PROTECTED] wrote: Here are a few drm patches. correct another lock leak. add missing link. negate return value. minor cleanup while we are here. It just panics my laptop (think due to another bug discovered): Unread portion of the kernel message buffer: info: [drm] Setting GART location based on new memory map bus_dmamem_alloc failed to align memory properly. I was seeing some instability before my patch, mainly xserver, sometimes kernel. Being that xorg is such a moving target (and this isn't my day job), I haven't spent the time to track it down. My machine is freebsd 7.0 stable from about 4/15/08, and pretty much pre mpx xorg running on a AMD64X2 and RV370. I also run compiz 7.4. What are you running? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BSD libdrm
On Thursday 01 May 2008 07:16:36 am Jerome Glisse wrote: On Tue, 29 Apr 2008 20:51:45 -0700 vehemens [EMAIL PROTECTED] wrote: The primary goal is to update the BSD drm code with the recent linux changes including linux drm memory management code. I haven't seen anything in the code that would prevent this from occurring, but I'm new at this. I don't know how close you are to BSD kernel people but i guess they are the one to know best what they want. I think linux will slowly (timeframe being a year or little bit more) move to kernel modesetting. So the question is does BSD folks like this idea or not, there is many security implication in this and getting it right is not trivial. So maybe ask the BSD kernel community on their feeling about drm and drm+memory manager+modesetting. I'll drop them a line, and see what suggestions they have. As a user, I would like to see most of the linux DRM features incorporated, If they like it, i suggest porting memory manager first, then modesetting (you need memory manager for modesetting at least i strongly discourage to do it without one). Currently I'm merging the core code which results in mostly using the linux code with some macros and ifdefs. There are a few things I plan to keep from the freebsd side however. Once I get the baseline merged, I will begin work on the memory manager. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
BSD libdrm Update
I'm currently working on updating the bsd libdrm for use with my freebsd system. To reduce the work involved, I'm using some code from the linux kernel for lists and atomics. This also greatly reduces the amount of unique code required. Unfortunately I only have radeon rv370 and intel i810 class hardware so my testing capability is somewhat limited. My thoughts are that i9i5 flavor hardware may be the best way to to check out the code. Another option is to stick with radeon and to switch over to the mode-setting branch at some point. So does anyone have any ideas on what would be the best testing approach? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BSD libdrm
On Tuesday 29 April 2008 08:35:36 am Jerome Glisse wrote: On Mon, 28 Apr 2008 08:26:41 -0700 vehemens [EMAIL PROTECTED] wrote: I'm currently working on updating the bsd libdrm for use with my freebsd system. To reduce the work involved, I'm using some code from the linux kernel for lists and locks. This also greatly reduces the amount of unique code required. Unfortunately I only have radeon rv370 and intel i810 class hardware so my testing capability is somewhat limited. My thoughts are that i9i5 flavor hardware may be the best way to to check out the code. Another option is to stick with radeon and to switch over to the mode-setting branch at some point. So does anyone have any ideas on what would be the best testing approach? What are your aims ? As far as i know BSD/drm does not have memory manager support thus modesetting is not operational on BSD as it needs the memory manager. libdrm so far is a pretty small layer on top of kernel interface to make userspace life easier. For testing current BSD functionalities i believe a working 3D acceleration under X is the best use case given that DRM is primilary designed and written for this usage. The primary goal is to update the BSD drm code with the recent linux changes including linux drm memory management code. I haven't seen anything in the code that would prevent this from occurring, but I'm new at this. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
BSD libdrm
I'm currently working on updating the bsd libdrm for use with my freebsd system. To reduce the work involved, I'm using some code from the linux kernel for lists and locks. This also greatly reduces the amount of unique code required. Unfortunately I only have radeon rv370 and intel i810 class hardware so my testing capability is somewhat limited. My thoughts are that i9i5 flavor hardware may be the best way to to check out the code. Another option is to stick with radeon and to switch over to the mode-setting branch at some point. So does anyone have any ideas on what would be the best testing approach? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Mesa3d-dev] Make TarBalls Broken
Removing the glcore: drop outdated sources files intented for xorg has also broken make tarballs. Is there a distribution patch coming in the near future? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] RADEON RV350 Rendering Stalls
I'm seeing my RADEON RV350 stall (~1 FPS) when running the engine demo with the wire frame rendering style. The other styles run ~140 FPS. Switching to a RV250 results in ~160 FPS or better for all rendering styles. This is with the MESA/DRI/ATI/X development master branches as of the last few days. I don't have data on when the problem started. Anyone else seeing this problem, or have any suggestions on where the cause might be? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: DRM_ERR Removal
On Monday 23 July 2007 07:59:24 am Eric Anholt wrote:
This was used to make all ioctl handlers return -errno on linux and
errno on *BSD. Instead, just return -errno in shared code, and flip sign
on return from shared code to *BSD code.
I was trying to determine why my system hung and focused on the shared code
change. Then I decide it was time to forage for food after looking at the
commit diff.
There are a couple of problems with the BSD driver however.
1) Locking is broken in drm_auth.c causing my system to hang. Patch is at the
end of this email. I pasted it in as well as attaching it as I have had
problems on other mailing lists with attachments.
2) In drm_getstats, memset(stats, 0, sizeof(stats)) should be
memset(stats, 0, sizeof(drm_stats_t)). Could also of used bzero.
3) In drm_setversion, retv is never used. I changed the routine to work as
before, but havn't yet read the drm specification on what should occur or
looked at the rest of the code to see if it matters.
--- bsd-core/drm_auth.c.orig2007-07-21 23:13:43.0 -0700
+++ bsd-core/drm_auth.c 2007-07-25 01:43:08.0 -0700
@@ -1,4 +1,4 @@
-/* drm_auth.h -- IOCTLs for authentication -*- linux-c -*-
+/* drm_auth.c -- IOCTLs for authentication -*- linux-c -*-
* Created: Tue Feb 2 08:37:54 1999 by [EMAIL PROTECTED]
*/
/*-
@@ -66,7 +66,6 @@
entry-priv = priv;
entry-next = NULL;
- DRM_LOCK();
if (dev-magiclist[hash].tail) {
dev-magiclist[hash].tail-next = entry;
dev-magiclist[hash].tail = entry;
@@ -74,7 +73,6 @@
dev-magiclist[hash].head = entry;
dev-magiclist[hash].tail = entry;
}
- DRM_UNLOCK();
return 0;
}
@@ -88,7 +86,6 @@
DRM_DEBUG(%d\n, magic);
hash = drm_hash_magic(magic);
- DRM_LOCK();
for (pt = dev-magiclist[hash].head; pt; prev = pt, pt = pt-next) {
if (pt-magic == magic) {
if (dev-magiclist[hash].head == pt) {
@@ -100,11 +97,9 @@
if (prev) {
prev-next = pt-next;
}
- DRM_UNLOCK();
return 0;
}
}
- DRM_UNLOCK();
free(pt, M_DRM);
return EINVAL;
@@ -129,8 +124,8 @@
continue;
} while (drm_find_file(dev, auth-magic));
file_priv-magic = auth-magic;
- DRM_UNLOCK();
drm_add_magic(dev, file_priv, auth-magic);
+ DRM_UNLOCK();
}
DRM_DEBUG(%u\n, auth-magic);
@@ -152,8 +147,8 @@
drm_remove_magic(dev, auth-magic);
DRM_UNLOCK();
return 0;
- } else {
- DRM_UNLOCK();
- return EINVAL;
}
+
+ DRM_UNLOCK();
+ return EINVAL;
}
--- bsd-core/drm_auth.c.orig 2007-07-21 23:13:43.0 -0700
+++ bsd-core/drm_auth.c 2007-07-25 01:43:08.0 -0700
@@ -1,4 +1,4 @@
-/* drm_auth.h -- IOCTLs for authentication -*- linux-c -*-
+/* drm_auth.c -- IOCTLs for authentication -*- linux-c -*-
* Created: Tue Feb 2 08:37:54 1999 by [EMAIL PROTECTED]
*/
/*-
@@ -66,7 +66,6 @@
entry-priv = priv;
entry-next = NULL;
- DRM_LOCK();
if (dev-magiclist[hash].tail) {
dev-magiclist[hash].tail-next = entry;
dev-magiclist[hash].tail = entry;
@@ -74,7 +73,6 @@
dev-magiclist[hash].head = entry;
dev-magiclist[hash].tail = entry;
}
- DRM_UNLOCK();
return 0;
}
@@ -88,7 +86,6 @@
DRM_DEBUG(%d\n, magic);
hash = drm_hash_magic(magic);
- DRM_LOCK();
for (pt = dev-magiclist[hash].head; pt; prev = pt, pt = pt-next) {
if (pt-magic == magic) {
if (dev-magiclist[hash].head == pt) {
@@ -100,11 +97,9 @@
if (prev) {
prev-next = pt-next;
}
- DRM_UNLOCK();
return 0;
}
}
- DRM_UNLOCK();
free(pt, M_DRM);
return EINVAL;
@@ -129,8 +124,8 @@
continue;
} while (drm_find_file(dev, auth-magic));
file_priv-magic = auth-magic;
- DRM_UNLOCK();
drm_add_magic(dev, file_priv, auth-magic);
+ DRM_UNLOCK();
}
DRM_DEBUG(%u\n, auth-magic);
@@ -152,8 +147,8 @@
drm_remove_magic(dev, auth-magic);
DRM_UNLOCK();
return 0;
- } else {
- DRM_UNLOCK();
- return EINVAL;
}
+
+ DRM_UNLOCK();
+ return EINVAL;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM_ERR Removal
Isn't DRM_ERR() required for compatibility? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RADEON/AIGLX DRI Lock At Initialization
On Monday 09 July 2007 02:51:37 am Michel Dänzer wrote: On Mon, 2007-07-09 at 00:38 -0700, vehemens wrote: I believe I have narrowed the problem down to __glXDRIscreenProbe() removing the RADEON DRM lock that was set up with DRIFinishScreenInit(). What happens is that __glXDRIscreenProbe() calls drmOpenOnce() which uses drmAvailable() to test for the presence of the kernel driver. If the test passes, it closes the file descriptor and removes the lock. drmAvailable() opens and closes its own DRM file desriptor, which shouldn't have such side effects on existing DRM file descriptors. Could there be a bug in the DRM BSD code? Does the same problem occur on Linux for you? I've never seen it, FWIW. I was told that I should address this problem here. I'm running freebsd and xorg current. Is there a document that lists which descriptors are used by a particular component? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
xorg7.2 upgrade and glxgears
I have the following error when running glxgears using the ATI driver:
X Error of failed request: BadRequest (invalid request code or no such
operation)
Major opcode of failed request: 158 (DAMAGE)
Minor opcode of failed request: 4 ()
Serial number of failed request: 37
Current serial number in output stream: 38
Also mesa-demos won't build with the NVIDIA patches. Here are my patches to
the makefile and a revised yuvrect_client.c patch (i.e. elif to else).
--- Makefile.orig Wed May 2 09:27:18 2007
+++ MakefileSat May 12 00:50:41 2007
@@ -96,9 +96,7 @@
.endif
.if defined(WITH_NVIDIA_GL)
-CFLAGS+= -DWITH_NVIDIA_GL=1
-.else
-CFLAGS+= -DWITH_NVIDIA_GL=0
+CFLAGS+= -DWITH_NVIDIA_GL
.endif
.include bsd.port.post.mk
--- progs/xdemos/yuvrect_client.c.orig Sat May 12 01:19:47 2007
+++ progs/xdemos/yuvrect_client.c Sat May 12 01:19:47 2007
@@ -140,7 +140,11 @@
exit(0);
}
- glx_memory = glXAllocateMemoryMESA(dpy, screen, ImgWidth * ImgHeight * 2,
0, 0 ,0);
+ #ifdef WITH_NVIDIA_GL
+ glx_memory = glXAllocateMemoryNV(ImgWidth * ImgHeight * 2, 0, 0 ,0);
+ #else
+ glx_memory = glXAllocateMemoryMESA(dpy, screen, ImgWidth * ImgHeight *
2, 0, 0 ,0);
+ #endif
if (!glx_memory)
{
fprintf(stderr,Failed to allocate MESA memory\n);
@@ -317,7 +321,11 @@
glXSwapBuffers(dpy, win);
event_loop(dpy, win);
- glXFreeMemoryMESA(dpy, DefaultScreen(dpy), glx_memory);
+ #ifdef WITH_NVIDIA_GL
+ glXFreeMemoryNV(glx_memory);
+ #else
+ glXFreeMemoryMESA(dpy, DefaultScreen(dpy), glx_memory);
+ #endif
glXDestroyContext(dpy, ctx);
XDestroyWindow(dpy, win);
XCloseDisplay(dpy);
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xorg7.2 upgrade and glxgears
On Saturday 12 May 2007 12:53:00 pm vehemens wrote: I have the following error when running glxgears using the ATI driver: X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 158 (DAMAGE) Minor opcode of failed request: 4 () Serial number of failed request: 37 Current serial number in output stream: 38 Downgrading libGL to 6.5.2 allows me to run glxgears. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: r500 - where to start?
On Saturday 23 December 2006 14:23, Jerome Glisse wrote: On 12/23/06, Magnus Ahlberg [EMAIL PROTECTED] wrote: I know that there has been some discussion about the r500 chip and how tough it will be to create a working driver for it. However, I for one would love to see an open alternative to the fglrx and I want to know, where to start? I own a laptop with a X1600 mobility radeon card. I am myself planning to take a look into that matter in the few coming days. Maybe i will got somethings in couple of day. I started looking at the xorg ati driver as well. Here are a few of my ideas/comments: Need to work the current driver to bypass pre 520 mode and 3d. Not sure about 2d. Finding and using the mode registers don't seem to be a big problem. Just need to do it. The I2C interface has been replaced with a byte based state machine (i.e. no more bit banging). - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [is somebody working on a xorg 7.1 port to FreeBSD ?]
On Thursday 03 August 2006 23:12, [EMAIL PROTECTED] wrote: What error message exactly you have got? The build procedure should look like this (assume we're installing in /work/x11r7: 1) downlod Xorg source, unpack 2) download mesa src 2) install devel/gnu-autoconf, devel/gnu-automake 3) mkdir -p /work/x11r7/share/aclocal 4) mkdir -p /work/x11r7/lib/pkgconfig 5) setenv PATH /usr/local/gnu-autotools/bin:/work/x11r7/bin:$PATH setenv ACLOCAL aclocal -I /usr/local/gnu-autotools/share/aclocal -I /usr/local/ share/aclocal -I /work/x11r7/share/aclocal -I /usr/X11R6/share/aclocal setenv PKG_CONFIG_PATH /work/x11r7/lib/pkgconfig:/usr/X11R6/libdata/pkgconfig 6)cd srcdir 7) ./util/modular/build.sh -m PATH_TO_MESA /work/x11r7 -n -s sudo /work/x11r7 Hope this helps Thanks for the help. It allowed me to run the server. The problem was a result of my not including the libtool macros with: setenv ACLOCAL aclocal -I /usr/local/share/aclocal There appears to be a number of other problems with building the code out of the box. Here is my current list: 1) Script git_xorg doesn't pull xserver, font and xcb files. Modified script to pull/update files. 2) Xcb doesn't build (needs gnome?). Used setenv USE_XCB NO for now. 3) Apps rendercheck and xdriinfo don't build. 4) A number of other apps aren't in the build script. 5) A number of video drivers don't build. Many of them due to missing GL headers. Copying in the headers allowed many of them to build. 6) Xkbdata doesn't build (missing?). 7) Fonts arabic-misc and mutt-misc don't build. Added empty README files. 8) Mesa current doesn't build (multiple problems?). 9) A lot of freebsd and mesa scripts are hardcoded with /usr/X11R6 requiring additional work to have multiple builds. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
is somebody working on a xorg 7.1 port to FreeBSD ?
ssedov at mbsd.msk.ru wrote: You can install X.org from GIT repository - it works fine out-of-the-box on freebsd. Just install it under the different PREFIX (e.g. /usr/x11r7) and you will not have problems with uninstall. I don't appear to have the same luck as I'm having problems with several of the autotool macros such as AM_PROG_LIBTOOL. Found an email that mentioned there was regression in libtool 1.5.22, but not sure if it is applicable is this case. I'm using 6.1 with a drm patch from 6.0 current along with ports as of 7/28/06 and xorg as of 8/1/06. Got any ideas on whats wrong? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
is somebody working on a xorg 7.1 port to FreeBSD ?
IMHO you should wait until we are ready to do a test-run on pointyhat. Otherwise you are going to be finding problems one-at-a-time that we can otherwise find out in bulk. How does one get access to the port code? To reiterate: there is very active work to get us to xorg7. It's not as trivial as some people have thought it is. What are the obstacles to incorporating xorg7.1 into ports? v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
X11R7.1 Into Ports
Is there a plan to get X11R7.1 into the ports tree in the next week or two? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RADEON Scratch Register Usage
On Monday 28 November 2005 02:55 pm, Benjamin Herrenschmidt wrote: The DRM lock should protect that ... note that I just spotted a DRM fix drm: fix quiescent locking going into the linux kernel that may explain races with the DRM lock. Also, there has been historical issues with the scratch register writeback. Have you tried disabling writeback via AGP ? I'm using FreeBSD 6.0 so it's unlikely that it's a kernel locking problem, at least not the same one. I did find what appears to be a single client Mesa problem which I now have a workaround for. I'll try running multiple client again this week or next. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM/Mesa Patches
Posting my latest DRM and Mesa patches in case they should prove useful to
anyone else. They are to head as of early Saturday.
I moved the CP idle outside the while loop in radeon_state.c. I think it may
apply to the R300 as well as there is an if R300 idle command in the
Xserver RADEONEnterServer function.
I have not tried removing the DRM changes since adding the Mesa change. Just
sticking with something that doesn't lockup.
diff -ru drm120205/shared-core/radeon_state.c
drmbld/shared-core/radeon_state.c
--- drm120205/shared-core/radeon_state.cMon Nov 28 22:05:43 2005
+++ drmbld/shared-core/radeon_state.c Sat Dec 3 13:00:57 2005
@@ -2388,7 +2388,7 @@
*/
BEGIN_RING(2);
- RADEON_WAIT_UNTIL_3D_IDLE();
+ RADEON_WAIT_UNTIL_IDLE();
ADVANCE_RING();
@@ -2737,6 +2737,7 @@
drm_radeon_cmd_header_t header;
int orig_nbox, orig_bufsz;
char *kbuf = NULL;
+ RING_LOCALS;
LOCK_TEST_WITH_RETURN(dev, filp);
@@ -2775,7 +2776,17 @@
}
orig_nbox = cmdbuf.nbox;
-
+
+ /* Wait for the engine to idle before the indirect buffer
+* is processed.
+*/
+
+ BEGIN_RING(2);
+
+ RADEON_WAIT_UNTIL_IDLE();
+
+ ADVANCE_RING();
+
if(dev_priv-microcode_version == UCODE_R300) {
int temp;
temp=r300_do_cp_cmdbuf(dev, filp, filp_priv, cmdbuf);
@@ -2785,7 +2796,7 @@
return temp;
}
-
+
/* microcode_version != r300 */
while (cmdbuf.bufsz = sizeof(header)) {
header.i = *(int *)cmdbuf.buf;
diff -ru mesa120205/Mesa/src/mesa/drivers/dri/r200/r200_state_init.c
xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_state_init.c
--- mesa120205/Mesa/src/mesa/drivers/dri/r200/r200_state_init.c Fri Dec 2
00:56:29 2005
+++ xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_state_init.c
Sat Dec 3 12:09:32 2005
@@ -253,8 +253,8 @@
ALLOC_STATE( zbs, always, ZBS_STATE_SIZE, ZBS/zbias, 0 );
ALLOC_STATE( tf, tf, TF_STATE_SIZE, TF/tfactor, 0 );
if (rmesa-r200Screen-drmSupportsFragShader) {
- if (rmesa-r200Screen-chip_family == CHIP_FAMILY_R200) {
- /* make sure texture units 0/1 are emitted pair-wise for r200 t0 hang
workaround */
+ if (rmesa-r200Screen-chip_flags R200_CHIPSET_TEX01_BROKEN) {
+ /* make sure texture units 0/1 are emitted pair-wise for t0 hang
workaround */
ALLOC_STATE( tex[0], tex_pair, TEX_STATE_SIZE_NEWDRM, TEX/tex-0,
0 );
ALLOC_STATE( tex[1], tex_pair, TEX_STATE_SIZE_NEWDRM, TEX/tex-1,
1 );
ALLOC_STATE( tam, tex_any, TAM_STATE_SIZE, TAM/tam, 0 );
@@ -273,7 +273,7 @@
ALLOC_STATE( afs[1], afs, AFS_STATE_SIZE, AFS/afsinst-1, 1 );
}
else {
- if (rmesa-r200Screen-chip_family == CHIP_FAMILY_R200) {
+ if (rmesa-r200Screen-chip_flags R200_CHIPSET_TEX01_BROKEN) {
ALLOC_STATE( tex[0], tex_pair, TEX_STATE_SIZE_OLDDRM, TEX/tex-0,
0 );
ALLOC_STATE( tex[1], tex_pair, TEX_STATE_SIZE_OLDDRM, TEX/tex-1,
1 );
ALLOC_STATE( tam, tex_any, TAM_STATE_SIZE, TAM/tam, 0 );
diff -ru mesa120205/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c
xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c
--- mesa120205/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c Fri Dec 2
00:56:29 2005
+++ xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c Sat
Dec 3 12:13:52 2005
@@ -1678,11 +1678,10 @@
r200ChooseVertexState( ctx );
- if (rmesa-r200Screen-chip_family == CHIP_FAMILY_R200) {
+ if (rmesa-r200Screen-chip_flags R200_CHIPSET_TEX01_BROKEN) {
/*
- * T0 hang workaround -
- * not needed for r200 derivatives
+ * T0 hang workaround
*/
if ((rmesa-hw.ctx.cmd[CTX_PP_CNTL] R200_TEX_ENABLE_MASK) ==
R200_TEX_0_ENABLE
(rmesa-hw.tex[0].cmd[TEX_PP_TXFILTER] R200_MIN_FILTER_MASK)
R200_MIN_FILTER_LINEAR) {
diff -ru mesa120205/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h
xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h
--- mesa120205/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.hFri
Dec 2 21:21:24 2005
+++ xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_chipset.h
Sat Dec 3 19:47:56 2005
@@ -133,5 +133,6 @@
#define RADEON_CHIPSET_TCL (1 2)/* tcl support - any
radeon */
#define RADEON_CHIPSET_BROKEN_STENCIL (1 3)/* r100 stencil bug */
#define R200_CHIPSET_YCBCR_BROKEN (1 4)/* r200 ycbcr bug */
+#define R200_CHIPSET_TEX01_BROKEN (1 5)/* r200 texture pair
bug */
#endif /* _RADEON_CHIPSET_H */
diff -ru mesa120205/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c
xorgcursrc/xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c
--- mesa120205/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c Fri Dec 2
21:21:24 2005
+++
Re: RADEON Scratch Register Usage
On Monday 28 November 2005 02:55 pm, Benjamin Herrenschmidt wrote: On Mon, 2005-11-28 at 02:18 -0800, vehemens wrote: I've been looking at my remaining lockups, and find that I keep coming back to the use of scratch registers in the driver for one of them. If I'm reading the code correctly, the scratch registers are per device, not per client. This would mean that you can't run more then one client without the potential of one stepping on the other. My read of the MESA code suggests that a stepped on client could then stall out waiting for a condition that would probably never happen (non-deterministic anyway). Does this sound correct, or am I missing something? The DRM lock should protect that ... note that I just spotted a DRM fix drm: fix quiescent locking going into the linux kernel that may explain races with the DRM lock. Also, there has been historical issues with the scratch register writeback. Have you tried disabling writeback via AGP ? Ben. Thanks for the pointers. It helped. What I did find is that I have random lockups during texture updates, and that it's easy to trigger. Still looking into the root cause. Noticed that the surface ioctl's do not have locking yet touch the ring via radeon_apply_surface_regs. Didn't seem to be a problem in my case. Don't all ioctl's that touch the ring need to be locked?? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RADEON Scratch Register Usage
I've been looking at my remaining lockups, and find that I keep coming back to the use of scratch registers in the driver for one of them. If I'm reading the code correctly, the scratch registers are per device, not per client. This would mean that you can't run more then one client without the potential of one stepping on the other. My read of the MESA code suggests that a stepped on client could then stall out waiting for a condition that would probably never happen (non-deterministic anyway). Does this sound correct, or am I missing something? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Radeon RV250 Lockup
I've managed to eliminate a number of lockups when running one or more copies
of glxgears and other GL programs with the patch below.
This suggests that the driver needs some type of command timing/processing
rules to prevent lockup (NOPs?).
I working on the other lockups, but debug seems to fix the problem which is
another indicator that the remaining problems are due to timing.
*** drm111605/shared-core/radeon_state.cFri Nov 11 20:25:43 2005
--- drmbld/shared-core/radeon_state.c Wed Nov 23 11:35:29 2005
***
*** 2737,2742
--- 2737,2743
drm_radeon_cmd_header_t header;
int orig_nbox, orig_bufsz;
char *kbuf = NULL;
+ RING_LOCALS;
LOCK_TEST_WITH_RETURN(dev, filp);
***
*** 2791,2796
--- 2792,2802
header.i = *(int *)cmdbuf.buf;
cmdbuf.buf += sizeof(header);
cmdbuf.bufsz -= sizeof(header);
+
+ /* hack */
+ BEGIN_RING(2);
+ RADEON_WAIT_UNTIL_IDLE();
+ ADVANCE_RING();
switch (header.header.cmd_type) {
case RADEON_CMD_PACKET:
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV250 Lockup
I appear to of eliminated my remaining lockups by also idling the 2D engine in
radeon_cp_indirect which is being called from the xserver. Here is my latest
patch.
*** drm111605/shared-core/radeon_state.cFri Nov 11 20:25:43 2005
--- drmbld/shared-core/radeon_state.c Wed Nov 23 22:15:17 2005
***
*** 2388,2394
*/
BEGIN_RING(2);
! RADEON_WAIT_UNTIL_3D_IDLE();
ADVANCE_RING();
--- 2388,2394
*/
BEGIN_RING(2);
! RADEON_WAIT_UNTIL_IDLE();
ADVANCE_RING();
***
*** 2737,2742
--- 2737,2743
drm_radeon_cmd_header_t header;
int orig_nbox, orig_bufsz;
char *kbuf = NULL;
+ RING_LOCALS;
LOCK_TEST_WITH_RETURN(dev, filp);
***
*** 2791,2796
--- 2792,2802
header.i = *(int *)cmdbuf.buf;
cmdbuf.buf += sizeof(header);
cmdbuf.bufsz -= sizeof(header);
+
+ /* hack */
+ BEGIN_RING(2);
+ RADEON_WAIT_UNTIL_IDLE();
+ ADVANCE_RING();
switch (header.header.cmd_type) {
case RADEON_CMD_PACKET:
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon RV250 Lockup
It took over an hour this time, but it locked up while running three different
demos.
Looks good.. but dude diff -u plz
I can't read context diffs to save my life...
Dave.
Done.
drmbld/shared-core/radeon_state.c
--- drm111605/shared-core/radeon_state.cFri Nov 11 20:25:43 2005
+++ drmbld/shared-core/radeon_state.c Wed Nov 23 22:15:17 2005
@@ -2388,7 +2388,7 @@
*/
BEGIN_RING(2);
- RADEON_WAIT_UNTIL_3D_IDLE();
+ RADEON_WAIT_UNTIL_IDLE();
ADVANCE_RING();
@@ -2737,6 +2737,7 @@
drm_radeon_cmd_header_t header;
int orig_nbox, orig_bufsz;
char *kbuf = NULL;
+ RING_LOCALS;
LOCK_TEST_WITH_RETURN(dev, filp);
@@ -2791,6 +2792,11 @@
header.i = *(int *)cmdbuf.buf;
cmdbuf.buf += sizeof(header);
cmdbuf.bufsz -= sizeof(header);
+
+ /* hack */
+ BEGIN_RING(2);
+ RADEON_WAIT_UNTIL_IDLE();
+ ADVANCE_RING();
switch (header.header.cmd_type) {
case RADEON_CMD_PACKET:
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
