Re: Mesa 8.0 Info

[vehemens]

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

[vehemens]

___
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

[vehemens]

The following reply was made to PR kern/150514; it has been noted by GNATS.

From: vehemens 
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

[vehemens]

The following reply was made to PR kern/150514; it has been noted by GNATS.

From: vehemens 
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"

kern/152354: Obsolete Files

[vehemens]

>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

[vehemens]

The following reply was made to PR kern/150514; it has been noted by GNATS.

From: vehemens 
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"

Re: kern/150514: [drm] [request] Reorganize DRM Directory to Support Driver Updates

[vehemens]

The following reply was made to PR kern/150514; it has been noted by GNATS.

From: vehemens 
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"

kern/150514: Reorganize DRM Directory to Support Driver Updates

[vehemens]

>Number: 150514
>Category:   kern
>Synopsis:   Reorganize DRM Directory to Support Driver Updates
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  update
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 12 23:50:04 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: vehemens
>Release:FreeBSD 9 and 8.1
>Organization:
>Environment:
>Description:
Reorganize DRM driver files into sub directories to support further driver 
updates.  Have not provided a patch as this change is relatively straight 
forward. The tasks are as follows:

1) Under src/sys/dev/drm, create sub directories: i915, mach64, mga, r128, 
radeon, savage, sis, tdfx and via

2) Move board specific driver files with the exception of xxx_drm.h files into 
sub directories

3) Update the include file path of the relocated files for the header files 
that were also relocated

4) Update src/sys/modules/drm driver makefiles .PATH for new file locations

5) Update sys/conf/files for new file locations


>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: RFC: libdrm repo

[vehemens]

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

[vehemens]

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

[vehemens]

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

[vehemens]

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

[vehemens]

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
> > > > > > > 
> >
> > 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 referri

Re: RFC: libdrm repo

[vehemens]

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

[vehemens]

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  
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 w

Re: RFC: libdrm repo

[vehemens]

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

[vehemens]

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  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

[vehemens]

On Sunday 22 November 2009 01:01:10 Dave Airlie wrote:
> On Sun, Nov 22, 2009 at 7:10 PM, vehemens  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.

Suggest that you actually read the emails and IRC comments.

Your lack of understanding on the value of the codebase is not in general my 
problem, except when you impact myself and others as you have done this time.

> Why bother adding code to a common tree that no operating system
> has any intention of shipping ever.

This simply isn't true.  Please don't make statements that are obviously 
false.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: RFC: libdrm repo

[vehemens]

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

[vehemens]

On Friday 20 November 2009 14:20:41 Kristian Høgsberg wrote:
> 2009/11/19 Eric Anholt :
> > On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote:
> >> 2009/11/6 Kristian Høgsberg :
> >> > 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

[vehemens]

On Tuesday 17 November 2009 08:33:30 Kristian Høgsberg wrote:
> 2009/11/6 Kristian Høgsberg :
> > 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

[vehemens]

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

[vehemens]

>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?

[vehemens]

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"

Re: svn commit: r190595 - head/sys/dev/drm

[vehemens]

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"

svn commit: r190595 - head/sys/dev/drm

[vehemens]

>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: drm: Branch 'r6xx-r7xx-support' - 117 commits

[vehemens]

On Sunday 29 March 2009 10:55:52 pm Alex Deucher wrote:

> New commits:
> commit c3c2ae466cfa1d4e079f6f0396e8f0f68ecb84b8
> Merge: 48b5f09... e2d7dfb...
> Author: Alex Deucher 
> 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.

[vehemens]

On Saturday 28 February 2009 05:28:38 am Pekka Paalanen wrote:
> On Fri, 27 Feb 2009 23:54:21 -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  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.

[vehemens]

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  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.

[vehemens]

On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote:
> On Fri, Feb 27, 2009 at 4:40 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.
>
> 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

Re: changes to upstreaming process for Linux code.

[vehemens]

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

next release of xineramaproto

[vehemens]

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

[vehemens]

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 
> > > 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 
>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

[vehemens]

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

[vehemens]

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

[vehemens]

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

[vehemens]

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: Unhappy Xorg upgrade

[vehemens]

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

[vehemens]

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: [HEADS UP] drm merged to -STABLE

[vehemens]

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

[vehemens]

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

[vehemens]

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

[vehemens]

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

[vehemens]

subject says it all
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: drm: Branch 'master'

[vehemens]

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 
> > >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

Re: drm: Branch 'master'

[vehemens]

On Wednesday 10 December 2008 03:52:08 pm Jesse Barnes wrote:
>...
>New commits:
>commit 9583c099b4a08b49e03f7b461c344b6d277fd262
>Author: Jesse Barnes 
>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

Missing libX11 Headers

[vehemens]

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?

[vehemens]

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?

[vehemens]

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

[vehemens]

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

Re: misc drm patches

[vehemens]

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

misc drm patches

[vehemens]

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: BSD libdrm

[vehemens]

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

Re: BSD libdrm

[vehemens]

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 Update

[vehemens]

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

BSD libdrm

[vehemens]

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

[vehemens]

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

Re: [Mesa3d-dev] RADEON RV350 Rendering Stalls

[vehemens]

On Monday 01 October 2007 12:07:25 am Michel Dänzer wrote:
> On Sun, 2007-09-30 at 18:40 -0700, vehemens wrote:
> > 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?
>
> *WARN_ONCE*
> File r300_render.c function r300Fallback line 364
> Software fallback:ctx->Line.SmoothFlag
> ***
>
> Enable the driconf option disable_lowimpact_fallback to trade in
> correctness for speed.

That did it.  Thanks.

-
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/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] RADEON RV350 Rendering Stalls

[vehemens]

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

[Mesa3d-dev] Use of bash Breaks Build

[vehemens]

The recent mesa commit that added "SHELL = /bin/bash" to the toplevel Makefile 
broke building on my FreeBSD 7.0 current system.


-
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/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: DRM_ERR Removal

[vehemens]

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

[vehemens]

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

[vehemens]

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

Re: xorg7.2 upgrade and glxgears

[vehemens]

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]"

xorg7.2 upgrade and glxgears

[vehemens]

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 


--- 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: r500 - where to start?

[vehemens]

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.php&p=sourceforge&CID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: pkgdb 2.2.2 is abysmally slow

[vehemens]

On Thu, Nov 23, 2006 at 21:36:53, Joe Marcus Clarke wrote:
> The pkgdb that ships with portupgrade-2.2.2 is orders of magnitude
> slower that that of 2.1.3.3.  On a machine with 472 ports, if I upgrade
> nspr the time to run pkgdb -fF after the upgrade is about ten minutes.
> Prior to upgrading to portupgrade-2.2.2, the same operation took about
> three seconds.  The result is portupgrades slow down to a crawl since
> pkgdb needs to be run between the build completion and the
> uninstall/upgrade portion.

It's really bad with 700+ ports (i.e. xorg modular, gnome ports, and a few 
others sprinked in).

Anybody know what the processing time is for "portupgrade -arRW" as a function 
of the number of ports before and after the last update?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: is somebody working on a xorg 7.1 port to FreeBSD ?

[vehemens]

On Thursday 03 August 2006 23:37, Mark Linimon wrote:
> As is asked and answered every week or so: yes.  It is not a simple matter
> of just plugging it in.

Given that it's asked every week, maybe somebody could provide weekly status 
to cut down on the questions ?}

Having tried xorg-modular-exp myself, I can see that there is a fair 
amount of work remaining to get it fully integrated.

Is the plan to have both 6.9 and 7.1 releases coexist to allow the 
rest of the collection to catch up?

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [is somebody working on a xorg 7.1 port to FreeBSD ?]

[vehemens]

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 ?

[vehemens]

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 ?

[vehemens]

>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

[vehemens]

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]"

DRM/Mesa Patches

[vehemens]

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
+++ xorgcurs

[Mesa3d-dev] DRM/Mesa Patches

[vehemens]

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
+++ xorgcurs

Re: [Mesa3d-dev] RV250 Texture Units

[vehemens]

On Sunday 04 December 2005 02:24 am, Dave Airlie wrote:
> > All I can say at this point is that this change along with a couple of
> > DRM kernel changes has allowed me for the first time to run opengl
> > programs (single client) for many hours without lockups.
>
> Wierd, I'd say more than likely you are just moving the problem around, as
> in there is a subtle race and you are just changing the timings...

It does appear to be timing related.  But I also found that the random nature 
of the problem could be eliminated (in this case anyway) by adding calls to 
radeon_do_cp_idle in the driver ioctls before doing any device I/O.

Once I did this, the problem always occured versus sometimes.  Probably some 
timing issue within the chip.


---
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=7637&alloc_id=16865&op=click
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] RV250 Texture Units

[vehemens]

On Friday 02 December 2005 08:40 pm, Roland Scheidegger wrote:
> vehemens wrote:
> > It appears that the RV250 (ChipID = 0x4966) may also require the
> > texture unit pair-wise workaround.
>
> That would imho be really strange since the chip physically has only one
> tmu per pipe, but who knows...
>
> > I found that by enabling the workaround, one of my lockup causes was
> >  eliminated (reduced? time will tell).
> >
> > Has anybody else seen this problem?
>
> No. However, maybe this could also be related to the still not quite
> working atom emit order, which for some reason doesn't work if it's
> random. If you emit the texture unit atoms pair-wise, there's one extra
> atom you're sending (with single-texturing) which might fix things in
> some cases, dunno.

I started looking at the driver code in detail, but it's going to take a while 
for me to explain why my fix works.  Not having chip docs doesn't help.

All I can say at this point is that this change along with a couple of DRM 
kernel changes has allowed me for the first time to run opengl programs 
(single client) for many hours without lockups.



---
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=7637&alloc_id=16865&op=click
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: RADEON Scratch Register Usage

[vehemens]

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=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Mesa3d-dev] RV250 Texture Units

[vehemens]

It appears that the RV250 (ChipID = 0x4966) may also require the texture unit 
pair-wise workaround.

I found that by enabling the workaround, one of my lockup causes was 
eliminated (reduced? time will tell).

Has anybody else seen this problem?


---
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=7637&alloc_id=16865&op=click
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: RADEON Scratch Register Usage

[vehemens]

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=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

RADEON Scratch Register Usage

[vehemens]

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=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Radeon RV250 Lockup

[vehemens]

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=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Radeon RV250 Lockup

[vehemens]

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=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Radeon RV250 Lockup

[vehemens]

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=7637&alloc_id=16865&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel