Re: licenses
Vladimir Dergachev wrote: On Wed, 27 Apr 2005, Keith Whitwell wrote: Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Dergachev wrote: Can someone enlighten me as to what is the license of R200 Mesa driver ? Also, what is the usual (accepted, preferred, etc..) license for a Mesa driver code ? Taken a look at the top of any the files in src/mesa/drivers/dri/r200? Here's what's there: /* $XFree86: xc/lib/GL/mesa/src/drv/r200/r200_lock.c,v 1.1 2002/10/30 12:51:52 alanh Exp $ */ /* Copyright (C) The Weather Channel, Inc. 2002. All Rights Reserved. The Weather Channel (TM) funded Tungsten Graphics to develop the initial release of the Radeon 8500 driver under the XFree86 license. This notice must be preserved. Basically the standard license for the Mesa drivers is the part from here down, plus a copyright line as above, with whoever you want as the copyright holder. So is it XFree86 license ? Pre or post 4.4.0 ? Or something else ? I would recommend avoiding confusion, and not using the name XFree86 license unless refering specifically to the XFree86 project. When refering to the XFree86 project's license, it is also best to indicate what specific version of the license you're refering to, as the older license was more or less MIT style, while the newer one has additional restrictions. MIT/X11 License is the traditional X license which most of the xc/* codebase is licensed under, including most drivers, etc. If adding a new driver to the tree, please license it MIT/X11. --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i830 driver status..
On Fri, 16 Jul 2004, Alex Deucher wrote: Date: Fri, 16 Jul 2004 09:06:26 -0400 From: Alex Deucher [EMAIL PROTECTED] To: Dave Airlie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII X-BeenThere: [EMAIL PROTECTED] Subject: Re: i830 driver status.. On Thu, 15 Jul 2004 08:22:42 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: Is the i830 driver considered to be dead, should any future work go towards the i915 one? just like to get a semi-official idea? if so we need to import the up to date DDX into the DRI tree and start releasing the snapshots for the i915 driver.. Sounds good to me. At this point perhaps we should just not worry about updating the DRI tree and just switch to using the XORG tree for DDX. it's a lot of hassle to have to maintain both trees and then moves changes back and forth. New dri DDX related work can happen on a branch maybe. Just a thought... I think it is a great idea if the DRI CVS tree moves into X.org, either on Xorg CVS head, or on a branch - either would be better than having so many different repositories to track, and merging would probably be much smoother also, and could possibly be done more often as well. Please bring this up on the [EMAIL PROTECTED] list if it hasn't already (haven't checked my xorg folder). The new release is looming on the near horizon for late August or thereabouts, so it would be nice if this change could occur before then. TTYL --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721alloc_id=10040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 849] [PATCH] Fix DRI pagesize assumptions in radeon and r128 drivers
On Sun, 11 Jul 2004, Patrick McFarland wrote: Date: Sun, 11 Jul 2004 02:32:00 -0400 From: Patrick McFarland [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii X-BeenThere: [EMAIL PROTECTED] Subject: Re: [Bug 849] [PATCH] Fix DRI pagesize assumptions in radeon and r128 drivers Does this fix the random crashing issue on ia32? ia64, alpha and other architectures have configureable page size, which is IIRC, a kernel compile time constant. If X is built to expect a specific pagesize on a given arch, it will break if the user changes their kernel's pagesize. The X server already tries to handle this all over, but from time to time glitches like this one are found. ia32 has a fixed 4k pagesize (not counting large pages of course), and so this patch does nothing on ia32. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Uninitialized variable 'size' used in r200TryReadPixels()
In XFree86 4.3.0, and also in current X.org X11, in the file:
xc/lib/GL/mesa/src/drv/r200/r200_pixel.c
inside the function r200TryReadPixels(), the variable size is
declared as:
static GLboolean
r200TryReadPixels( GLcontext *ctx,
GLint x, GLint y, GLsizei width, GLsizei height,
GLenum format, GLenum type,
const struct gl_pixelstore_attrib *pack,
GLvoid *pixels )
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
GLint size;
GLint pitch = pack-RowLength ? pack-RowLength : width;
GLint blit_format;
Later in the same function, the variable is passed uninitialized
to the function check_color():
if (!check_color(ctx, type, format, pack, pixels, size, pitch))
return GL_FALSE;
I'm not aware of any actual bug being triggered by this, but the
code is obviously incorrect. Later in the file, the function
r200TryDrawPixels() calls check_color also, passing it's own
local variable size, however size is declared in that function
as:
static GLboolean
r200TryDrawPixels( GLcontext *ctx,
GLint x, GLint y, GLsizei width, GLsizei height,
GLenum format, GLenum type,
const struct gl_pixelstore_attrib *unpack,
const GLvoid *pixels )
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
GLint pitch = unpack-RowLength ? unpack-RowLength : width;
GLuint dest, planemask;
GLuint cpp = rmesa-r200Screen-cpp;
GLint size = width * pitch * cpp;
I'm unfamiliar with this particular code, however it seems that
the same calculation being done in r200TryDrawPixels() would be
valid for r200TryReadPixels().
Does the patch I've attached look correct?
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - X.org X11 maintainer - Red Hat--- xc/lib/GL/mesa/src/drv/r200/r200_pixel.c.r200-uninitialized-variable-used
2004-03-26 03:49:15.0 -0500
+++ xc/lib/GL/mesa/src/drv/r200/r200_pixel.c2004-03-26 04:06:07.0 -0500
@@ -155,9 +155,10 @@
GLvoid *pixels )
{
r200ContextPtr rmesa = R200_CONTEXT(ctx);
- GLint size;
GLint pitch = pack-RowLength ? pack-RowLength : width;
GLint blit_format;
+ GLuint cpp = rmesa-r200Screen-cpp;
+ GLint size = width * pitch * cpp;
if (R200_DEBUG DEBUG_PIXEL)
fprintf(stderr, %s\n, __FUNCTION__);
[Dri-devel] Re: Uninitialized variable 'size' used in r200TryReadPixels()
On Fri, 26 Mar 2004, Mike A. Harris wrote: In XFree86 4.3.0, and also in current X.org X11, in the file: xc/lib/GL/mesa/src/drv/r200/r200_pixel.c [SNIP] I'm unfamiliar with this particular code, however it seems that the same calculation being done in r200TryDrawPixels() would be valid for r200TryReadPixels(). Does the patch I've attached look correct? Of course, 30 seconds after sending my email, I noticed that the check_color() function does not even use the sz parameter it is passed anywhere. Should check_color() just have that parameter removed, and all locations that use it updated to not pass that? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - X.org X11 maintainer - Red Hat --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Fw: Re: Savage driver in Mesa and DRI trunk
On Fri, 5 Mar 2004, Felix [ISO-8859-1] Kühling wrote: Date: Fri, 5 Mar 2004 16:47:50 +0100 From: Felix [ISO-8859-1] Kühling [EMAIL PROTECTED] To: Alex Deucher [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Subject: Re: Fw: Re: Savage driver in Mesa and DRI trunk On Fri, 5 Mar 2004 07:34:30 -0800 (PST) Alex Deucher [EMAIL PROTECTED] wrote: --- Felix K_hling [EMAIL PROTECTED] wrote: Mark, I'm forwarding your message to the dri-devel mailing list. I can't test randr here. Alex how much do you know about randr? Can you reproduce and problems? Unfortunately, I haven't really messed with randr much. I don't personally find much use for it. However I do have the same notebook Mark has so I may take a look at it. Does the dri cvs tree have xrandr in it? unfortunately that notebook has a pretty old distro on it. I just realized that I do have xrandr installed. I wasn't aware that it was part of XFree86 4.2.1 which I still have installed on my box. Or is it a Debian add-on? Either way, I'm going to look into it sometime. The xrandr client was added to 4.2.0, however only kdrive supports RandR in 4.2.0. You need 4.3.0 for RandR support in the core server. HTH --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: freedesktop CVS
On Mon, 1 Mar 2004, Leif Delgass wrote: Date: Mon, 1 Mar 2004 11:33:29 -0500 (EST) From: Leif Delgass [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: freedesktop CVS Hello, I'm not able to checkout the DRI CVS from freedesktop.org, since I seem to have been dropped from the dri group -- same problem that others had recently. I sent an email to Eric but apparently he's away for some time. Does anyone else on the list have the ability to modify groups on freedesktop.org? I've added Leif to the dri group earlier today, so that's fixed now. Let me know if anyone else is missing. Also, just a note so everyone knows what to do in case of any kind of administrative problems in the future... You can try joining #freedesktop on irc.freenode.net and ping myself, or other admins in realtime, and/or you can email [EMAIL PROTECTED] for asynchronous admin requests, and we'll try to fix up whatever is broke ASAP. Hope this helps, TTYL -- Mike A. Harris --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Savage 3D driver roadmap
On Fri, 20 Feb 2004, Alex Deucher wrote: the main reason mach64 is still on a branch in DRI is it is insecure by default, I'm going to look into it when I've moved apartments and got myself settled in again :-), I don't think putting insecure code into the trunk where it may get merged up to XFree86 is such a good idea :-) As I recall it's just a matter of changing a config option to a different default. should be trivial. Just needs to be added to DevelDRIDrivers in xfree86.cf -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: R9200SE Slowness
On Sat, 21 Feb 2004, Chris Ison wrote: ok, let me get this in perspective R9200R8500 DRI14.62103716.860273 fglrx39.46159444.228085 I have been trying to hunt down the slowdown in DRI, I even if (0)'s all occurances of sched_yield () which is slower in 2.6 than 2.4 due to 2.6 doing it properly. According to R200_DEBUG, there is no fallbacks used with glxgears and only vertex array fallbacks used for QuakeForge. This may be misleading however is the fallback debug option is only used in extreme fallbacks and not partial ones. also been looking at r200EmitState, for most of its calls, it emits nothing, but occassionally it does, been thinking about assing a switch or something that is set when there truely is something to emit, and bailout early in r200EmitState if there isn't. Thats as far as I've gotten so far. Is there anything else I should be looking at? oprofile perhaps might help. -- Mike A. Harris --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: GATOS and DRI merge
On Tue, 10 Feb 2004, Hod McWuff wrote: So, to summarize, I need to know *roughly* what's changed since the Gatos folks forked, in terms of what-moved-where and an idea of any structural changes. I can read the different sources and figure out the code changes myself, but I need to know what I'm looking for. Presumeably the best way to find out what the GATOS developer(s) changed, would be to ask them. ;o) It would seem the best approach is to merge their changes - conceptually, one by one - into the current DRI sources. That sounds sane, however some of it may require a bit of discussion to iron out issues. For example, anything that might break ABI would be a no-go. If I recall correctly, in the past there were ABI changing differences, however I have no idea if that is the case nowadays. That said, it would indeed be nice to have GATOS efforts work out of the box with one single unified driver set. -- Mike A. Harris --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Minimal fix for the R128 drivers
On Wed, 14 Jan 2004, Alan Cox wrote: Date: Wed, 14 Jan 2004 13:39:39 + From: Alan Cox [EMAIL PROTECTED] To: DRI Devel [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary==-aOYRP5LaOLpcWQuYBxVm Subject: Minimal fix for the R128 drivers I think this is about the minimal fix needed. I'm not entirely happy with the limits picked, especially for spans, but maybe someone with an R128 can verify it is ok, or change the code to loop each chunk of pixels/span data. If nobody objects to Alan's security patch, I'd like to commit it to CVS head for r128. -- Mike A. Harris --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: ATI R200 PCI
On Thu, 4 Dec 2003, Chris Ison wrote: I realize replies will be resticted under NDA, but I am unable to refine my questions until I can find the answers to the following questions in relation to ATI docs some developers have access too. 1. Do the ATI docs outline or detail expected PCI access process for the r200 chipset, and if so, how close does the code match to it. The ATI docs pretty much document the complete operation of the hardware for all intents and purposes. Not sure how better to answer your question, as it is kindof vague IMHO. 2. Do the docs specify expected process of initializing the card for both AGP and PCI and how close does the code match this. Again, kindof a vague question IMHO. 3. Are all registers mentioned in the docs also in the code. If you mean, is every single register in the Radeon specifications present in radeon_reg.h and actually used somewhere in the driver, the answer is definitely a resounding no. 4. From the published register information (under the NDI) is the detail enough to know if some registers need special handling, and if so, is this being done in the code exactly as detailed in the docs. What registers? Obviously the Radeon docs were used to write the driver, and are consulted by those who have them when fixing bugs and when adding new features, however nobody is a perfect programmer 100% and so there is definitely flaws in the driver, or it would be bug free. Again you're being very vague here. 5. Is there anything in the documentation in reguards to PCI or anything effecting PCI that is not implemented in the code Yes, it's entirely likely. PCI support was implemented for Alpha initially, and was never tested or contracted to work on anything else. SInce then various people (including yourself IIRC) have debugged different problems and got PCI support working better. There are definitely still bugs in the PCI support however, so that means that there are parts of the driver or kernel module missing code that is needed in order to make the cards function properly. You could interpret that as meaning the driver does not follow the documentation 100%, or it's possible that the docs are missing needed info, or it's much more likely that nobody has been interested enough to just debug and pound on the PCI support and work out any quirks on all hardware supported. and if so, is it possable to implement without breaching the NDA. Fixing bugs in the driver is always possible without breaching NDA. 6. Is there anything that is not implemented in the code that exists in the docs. For complete total support of all features on all Radeon hardware? Yes, absolutely. The OSS driver doesn't support anywhere near the complete functionality that the Windows drivers support on Radeon hardware, and probably never will, both from lack of volunteers to do the work, lack of people to fund the work, and various other factors. If so is the NDA preventing the implementation or has it been a case of time constraints. Implementation of what specifically? There are some advanced 3D features which are not implemented, which would require permission from ATI to do, but just as importantly would require someone wanting to actually do it, and dedicate time to do it, and that generally only happens when there is money involved, and big business contracts riding on it, such as the R200 3D support funded by The Weather Channel. I think that covers everything I wish to ask at this stage, and incase you are wondering, I am willing to help solve the mystery of the slow pci-gart, and the first place would appear to be comparing the docs to whats in the code and find any difference in implementation no matter how small. But since I don't have access to these docs I need the help of those that do. THe first step to me, would be to oprofile things, and find where the bottleneck is, then try to determine why. I doubt it would be that hard, and I doubt it requires the docs, although having the docs is always better than not having them when troubleshooting. If there are specific registers you don't understand and think might be a problem, or any other code construct, feel free to ask, and also to stick around in #dri-devel. While nobody can provide you the docs except ATI, we can probably clarify some uestions you might have about radeon hardware operation et al. IMHO, it's best to approach this from a direct concrete angle of a specific problem though, rather than a general problem of PCI not working properly and wanting to go over every inch of the driver anc compare register usage to the manual. The latter IMHO is a huge waste of time. -- Mike A. Harris --- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com
[Dri-devel] Re: Radeon PCI API
On Fri, 28 Nov 2003, Alex Deucher wrote: Date: Fri, 28 Nov 2003 23:08:04 -0800 (PST) From: Alex Deucher [EMAIL PROTECTED] To: Torgeir Veimo [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: Radeon PCI API Your best bet, if you can find one, is a fireGL 8800. It's basically an overclocked 8500. barring that the 8500's and 9100's are the next fastest. The 8800 is a faster R200 based board. It's not overclocked however. -- Mike A. Harris --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Bug 131] Metabug - Mach64 DRI is not merged into the [DRI] trunk.
On Fri, 7 Nov 2003, David Dawes wrote: --- Additional Comments From [EMAIL PROTECTED] 2003-07-11 06:30 --- So why this bug is closed? This is METABUG It is closed because it is neither a bug report or a submission, and is irrelevant to anyone tracking bugs for a release. This type of stuff belongs in your wiki. I totally agree here. People need to stop abusing bugzilla as a mailing list or wiki substitute. Bugzilla is for tracking defects, not for following the development of a driver or driver feature for 12 months through to completion. The whole concept of a METABUG whatever that is, is flawed. Create a mailing list for mach64-dri, or discuss it here please. Another similar bug is the Radeon IGP DRI bug report which has gone way out of hand IMHO and turned into a huge neverending mailing list substitute and/or web based tech support forum. http://bugs.xfree86.org/show_bug.cgi?id=314 That's just rediculous bugzilla abuse. I'm closing that one out too, and asking people to continue their endless discussion on the mailing lists, as it is equally abusive of bugzilla as the Mach64 DRI metabug. Please use dri-users and/or dri-devel for such discussions, not bugzilla. -- Mike A. Harris --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: More expat problems...
On Tue, 21 Oct 2003, Linus Torvalds wrote: glcontextmodes.o gets linked to libGL, not the driver. Apperently you have an outdated libGL installed. Well, my regular libGL.so is as new as the driver and compiled from DRI. And yes, _gl_context_modes_destroy is there according to 'nm'. HOWEVER - with the new Fedora test install, the system will actually have a libGL.so in /usr/X11R6/lib/tls/ too - and will find that one first. Removing the TLS-version of libGL solves the problem. So this is just a heads-up: I bet other people will hit this problem as they upgrade to Fedora test and the new RH library locations. Lots of people will likely inadvertently be hit by this unfortunately. My suggestion to everyone, is to uninstall the XFree86-Mesa-libGL package using: rpm -e --nodeps XFree86-Mesa-libGL As long as you know you're installing another rpm which provides libGL itself, then all rpm dependancies will be met properly and the --nodeps above is harmless. However if one installs outside of rpm context, such as from raw sources, then the system will have unmet rpm dependancies on libGL.so.1 and will complain about it. 2 solutions to that are: 1) Make sure any alternative libGL being installed is in rpm format or 2) Create a dummy rpm called fake-libGL-provide which contains no files, but which has lines like: Provides: libGL.so.1 By doing either of these, ensures rpm is happy, and that there shouldn't be any libGL conflicts. I made Mesa-libGL a separate subpackage to make replacing libGL easier for people to do. Hope this helps people to avoid such libGL probs. TTYL -- Mike A. Harris --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: new 2048 limit code...
On Fri, 24 Oct 2003, Alex Deucher wrote: Unless anyone says otherwise, I'm going to remove this code. All it has done is generate complaints from MergedFB users. Apparently it doesn't hurt anything (ie. cause a crash) to leave direct rendering enabled if the virtual desktop is larger than 2048. Since MergedFB users seem to be the only ones running into it, I don't see this affecting regular DRI users. I will put a warning in the code if the virtual res is larger than 2048 to let them know that they may run into issues. My suggestion would be to make it a config file option defaulting to the current behaviour. That way users who don't know any better get 3D working full desktop, but get an error/warning to the log file if their resolution goes beyond what is supported. Users who know what they're doing and want 3D on part of the desktop anyway can force enable it. That seems to be less problematic for most people IMHO, no? Anyhow, just a bit of feedback/suggestion, I don't have any hard opinion any way about it... And of course nothing is written in stone so whatever you go with can always be changed again later depending on user feedback, etc. TTYL -- Mike A. Harris --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: can't get dricvs to use radeon drm
On Wed, 22 Oct 2003, Chris Ison wrote: Have you done all the proper idiot checks? I hate to use the word that way, but that's how I'd phrase it if I were speaking to myself... Have you checked to make sure /dev/dri/card0 exists, has the proper major and minor numbers, and is readable and writeable by root? ok, /dev/dri/card0 doesn't exists, so why does it work for the SF dri and not the freedesktop one ... /dev/dri does exist, I'm thinking the SF drm creates /dev/dri/card0 but the freedesktop one doesn't, but I could be wrong. I will investigate this further by reverting back to the SF cvs. The DRI project officially moved the CVS repository from sourceforge to freedesktop.org, so the freedesktop.org is now the official DRI project CVS repository and the sourceforge CVS repository is completely obsolete. Don't use it. The DRM doesn't create device nodes on the filesystem (that would be totally insane). The X server itself creates /dev/dri/card* as needed. -- Mike A. Harris --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: kernel-2.6.0-test{7-8} and radeon drm segfault
On Sun, 19 Oct 2003, Donnie Berkholz wrote:
Date: Sun, 19 Oct 2003 14:12:59 -0400
From: Donnie Berkholz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol=application/pgp-signature; boundary==-b29xJgAX4aLDOTD7duZT
Subject: Re: kernel-2.6.0-test{7-8} and radeon drm segfault
On Sun, 2003-10-19 at 05:28, Louis Garcia wrote:
I've been playing with kernel-2.6 on redhat's latest beta. With my
radeon 7500 drm works great. When I boot to kernel-2.6 latest, I
modprobeagpgart, intel-agp and radeon. Startx and run glxinfo
and glxgears and both segfault. Anyone else seeing this? This
also happens if these are build statically. How is the stability of the
dri drivers in kernel-2.6.x?
Hi, I just dealt with this problem yesterday in Gentoo. You need to
prevent the patch named similar to Mesa-SSE-fixes-from-MesaCVS.patch
from being applied.
http://bugs.gentoo.org/show_bug.cgi?id=30541
Which of course would reinstate the bug that that patch fixes for
all 2.4.x users, which is the overwhelming majority of users out
there.
The proper fix is to fix both problems, not substitute one for
the other - although the latter is probably fine for homebrew
systems.
--
Mike A. Harris
---
This SF.net email sponsored by: Enterprise Linux Forum Conference Expo
The Event For Linux Datacenter Solutions Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; in the Server Room
http://www.enterpriselinuxforum.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Snapshots
On Fri, 10 Oct 2003, Felix [ISO-8859-1] Kühling wrote: there were 2 reports from snapshot users on dri-users that DRI was disabled with the new configuration stuff. In at least one case the problem was that libexpat was not installed on the system. Could the snapshot build be changed to link the drivers statically with libexpat? In either case I'll add a note in the FAQ. By all means allow the option to link statically to libraries if that is something considered useful, however please do not make this the default, as it: 1) Bloats code unnecessarily 2) Makes security updates a very complicated mess if expat needs to be updated to fix some security hole - you have to know every binary on the system that links statically to it. We had a wonderful time a year ago with updating zlib because so many software projects include the complete out of date zlib sources and link statically to their own copy. Bad juju. -- Mike A. Harris --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: ATI Radeon 9200 SE
On Sat, 13 Sep 2003, Michel [ISO-8859-1] Dänzer wrote: My Device section looks like: Section Device Identifier Radeon Driver radeon BusID PCI:1:0:0 Option AGPMode 4 Option AGPSize 128 BTW, I renamed this to GARTSize in current DRI CVS. Is AGPsize an alias? Or when people upgrade in the future will their configuration break if it is using AGPSize? -- Mike A. Harris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: ATI Radeon 9200 SE
On Sun, 14 Sep 2003, Michel [ISO-8859-1] Dänzer wrote: I think when things like this are changed, it is important to both document it widely, and also provide a backward compatibility mechanism. Otherwise it confuses users, and can cause tech support problems. Well, this option isn't documented widely in the first place. That doesn't mean it's not widely used though. It is documented, and so people do use it, although I certainly never recommend it to people. ;o) Anyway, you should have read my second followup before sending out yours. :) I read/respond serially usually. Might want to update docs to show they're aliases too, to avoid confusion also. ;o) -- Mike A. Harris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: ATI Radeon 9200 SE
On Sun, 14 Sep 2003, Michel [ISO-8859-1] Dänzer wrote: Anyway, you should have read my second followup before sending out yours. :) I read/respond serially usually. Can't Pine do better? :P Might want to update docs to show they're aliases too, to avoid confusion also. ;o) I'll gladly do so if you show me where it's documented. radeon manpage -- Mike A. Harris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: ATI Radeon 9200 SE
On Sun, 14 Sep 2003, Michel [ISO-8859-1] Dänzer wrote: Date: Sun, 14 Sep 2003 13:29:07 +0200 From: Michel [ISO-8859-1] Dänzer [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 Subject: Re: ATI Radeon 9200 SE On Sun, 2003-09-14 at 13:22, Mike A. Harris wrote: On Sun, 14 Sep 2003, Michel [ISO-8859-1] Dnzer wrote: Might want to update docs to show they're aliases too, to avoid confusion also. ;o) I'll gladly do so if you show me where it's documented. radeon manpage Doesn't mention it in any of the trees I have, only found one which does on the web - vendor specific patch? Ah, could be. I searched google, as it was easier than trying to search manpages/html/ps/etc. docs that come with X to try to find the various places it might show up. IMHO it should be documented somewhere however unless it's considered a developer only option. If it's developer-only perhaps it should be only enabled for debug builds? -- Mike A. Harris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: XFree86 merge
On Fri, 12 Sep 2003, Alan Hourihane wrote: Do DRI developers need to worry about that ? It's no problem for me personally, no idea about other developers, but what about users? They didn't have IPv6 before, so if it doesn't work now, there's still no problem for users. The problem with the IPv6 support commited to XFree86 CVS, was that it requires the system to have IPv6 support wether you actually use IPv6 at all or not. In other words, if your kernel does not support IPv6, then you can not use XFree86 CVS as it requires IPv6 unconditionally to be available on the system wether or not the X server will actually be used with IPv6. That was the original problem, however I do not know if that is still the case or wether it's been fixed now or not. It's possible that someone fixed the IPv6 to not be unconditional, but if it did get fixed, I must have missed seeing the checkin. If the issue is still present however, then anyone compiling XFree86 CVS and using it must have IPv6 on their system, even if they don't use it. Hope this helps. TTYL -- Mike A. Harris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Sourceforge CVS
On Wed, 3 Sep 2003, Alan Hourihane wrote: Havoc, your comment on pserver being like telnet isn't really applicable, anon only pserver is as secure as any anon only service, I wouldn't even think about using non-anon pserver but I don't think DRI will ever need such a thing.. Just a question of bandwidth/load then. I'm willing to try it. When we get general freedesktop.org anon mirrors we can always move to using those. To give you an idea of plans for the hosting and current status: https://listman.redhat.com/archives/xdg-list/2003-September/msg1.html So what we can do is include DRI in the migration plan. From you guys we probably need details on the exact stuff to be hosted, and how you want to set it up; and I'd guess someone from DRI should have admin access to the server (let us know who). OK. If anyone is deeply unhappy with the idea of moving to freedesktop.org for cvs hosting, it's time to speak up. One question. Would this be a temporary thing or permanent move ? If temporary then I guess I'd rather just see a anoncvs mirror setup rather than move it in the first place. But if it's permanent, then it's o.k. with me. Obviously we wouldn't tear down the CVS at SF, but we'd need to update the website to point people where to grab the new CVS. My original suggestion was for freedesktop.org to be the new permanent home for DRI. Assuming the server load works out ok, which I think it probably will, there shouldn't really be any problems. How many people out there use DRI anoncvs? We can also set up cvsup, and recommend it to people instead of CVS, which can help out significantly also. I'll install cvsupd on the machine so it can be enabled when needed. -- Mike A. Harris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Sourceforge CVS
On Tue, 2 Sep 2003, Keith Whitwell wrote: What is wrong right now is that we can't get uptodate versions of the repository to non-developers. Non-developers currently don't have BK, arch, subversion or even cvsup installed. They do seem to often have CVS installed, and we've successfully used it in the past to iterate test-debug-patch cycles. I don't think we can expect them to be installing a new version tool to participate in that existing process. A lot of them do have rsync, but even that wasn't installed by default in redhat until pretty recently. It's also a lot less rich than cvs. So, anonymous cvs is probably our best bet for rapid distribution of changes etc to users. This means two things 1) we need to fix anonymous CVS now 2) the discussion of developer version control system doesn't impact the fact that we need to fix anonymous CVS access for non-developers, so is not to be considered in any way urgent, imminent or even likely. If we ever did move to a different system, I think we'd want to keep an anonymous CVS access for non-developer access. So, right now, the urgent thing is to find a reliable site to host our cvs, including pserver anonymous cvs. No need for a flame war, talk of other version systems is basically idle banter and healthy venting of frustration. I expect we'll be using cvs for some time to come, if not longer. I can start creating user accounts on freedesktop.org and setup whatever infrastructure is needed right away, assuming the project favours the idea. All I need is DRI project members to email me, [EMAIL PROTECTED], or [EMAIL PROTECTED] their ssh DSA keys, and let us know what is needed. I can set up user accounts, and provide admin access to those who need it as well. rsync/cvsup/etc. are either installed already or can be ready to go in short order also. I'll also need to know which email address anyone prefers to have their email forwarded to. dri.freedesktop.org sound good? -- Mike A. Harris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Opteron, GinGin and PCIGart
On Thu, 17 Jul 2003, Ian Romanick wrote: Date: Thu, 17 Jul 2003 09:35:09 -0700 From: Ian Romanick [EMAIL PROTECTED] To: [EMAIL PROTECTED], DRI developer's list [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Subject: Re: Opteron, GinGin and PCIGart Mark Lane wrote: I am getting a weird error when attempting to run ForcePCIMode on an opteron with a Radeon 7500 PCI. I have also used a 7000 with the same results. (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... I am running the stock XFree86 which comes with GinGin. There are some known potential problems with the Radeon driver on 64-bit. Right now, none of the DRI developers (that I know of) have access to any 64-bit hardware, so you're venturing into uncharted I do. ;o) Just not the time. ;o/ territory. One question, though. Are you running in mixed 32-bit / 64-bit mode, or is everything (i.e., X-server, kernel, applications) built for 64-bit? If he's using the GinGin64 supplied binaries and kernel, he's using a complete 64bit kernel+userland including X. I believe it is probably a DRM issue that needs a few pokes with a stick. I'm going to try to reproduce it on ia64 also to see if it is likely a 64bit issue or just an architectural oddity. Either is possible. I haven't tried 4.3.0 on Alpha yet, but that might be a good idea too. Take care guys, TTYL -- Mike A. Harris --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: spam collection of the past few days
On 17 Jun 2003, Michel Dänzer wrote: And I have to say I'd be willing to stand down and let someone take over. The amount of spam I have to keep clearing anyway is time consuming to say the least. If I were to make the lists subscriber only, this task would only increase. So if anyone wants to take my place, just say so. I've already volunteered to take on a share. I obviously wouldn't want to do it all myself either. Any other takers? I volunteer as well. I maintain a few lists already which only permit subscriber posting, and while the spam load on those lists is much less than dri-devel, I don't mind helping keep the admin queue empty. My sourceforge name is mharris, feel free to add me to any/all of the DRI lists, just let me know which one's I'm on. ;o) -- Mike A. Harris --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: __MUST_HAVE_AGP
On Wed, 11 Jun 2003, [iso-8859-15] José Fonseca wrote: Are there some radeon AGP cards able to work without agpgart? Which drivers are you using? PCI support in Radeon was busted some time ago, which meant that AGP had to be present. To be clearer to the original person, PCI DRI support didn't work except on Alpha architecture. Radeon hardware worked fine in 2D only with DRI disabled though, on both AGP and PCI cards. I have an nvidia NFORCE1-based motherboard. Agpgart module does not support my north bridge: does this mean that I can't accelerate any AGP card (radeon 7200 for example)? That's a difficult question. I don't know whether the Radeon hardware allows to be run in PCI mode. All Radeon hardware should work fine in PCI mode. Wether or not XFree86/DRI drivers are up to scratch on a given XFree86 release or not is another question though. It is much better nowadays than in the past though. The issue is that the Radeon driver for PCI cards relies on the existence of a PCI-GART (it does the same as the AGP GART, but in the PCI bus) which I don't know if it's present on AGP cards. It is, and should work on AGP cards just like a PCI card, with ForcePCIMode. -- Mike A. Harris --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: SPAM : DRI Devel ratio
On Wed, 28 May 2003, Sven Luther wrote: I was being sarcastic, his message was encoded with koi8-r, which, along with being html, is one of the indescriminate reasons people block email (and get a good number of false positives) however, foreign language encoding is separate from html email. blocking based on foreign language encodings is not such a good idea. blocking html is not so bad, though. You need to block multi-part mails with only one html part too though, which is not so easy to do, i think. This filter doesn't catch *everything*, but for the last 6 years or so, it has had zero false positives for me while subscribed to limitless numbers of mailing lists. :0: * ^Content-Type:.*text/html HTML I go through the HTML folder occasionally, and all of the stuff is junk spam. There may be the opportunity for false positives, but in practice over the years, I've yet to see any with my mail load. Different people's mail usage may vary however... Hope this helps. -- Mike A. Harris --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: XFree86 bugzilla available
On Wed, 19 Mar 2003, Philip Brown wrote: An XFree86 bugzilla is now available at http://bugs.xfree86.org/. Many thanks to Hewlett-Packard for supplying the hardware, netSweng for hosting, and the many developers who helped configure and test it. This is great news. I think a great job was done organizing the products and components. I dont get it. Why is this suddenly great news, when DRI could have been using sourceforge's bugtracking system all this time? Because sourceforge's bug tracking system sucks? [1] However, it seems the decision to abandon that methodology was somehow made around 2001, judging by all the bug reports already sitting on http://sourceforge.net/tracker/?group_id=387atid=100387 Because sourceforge's bug tracking system sucks? [1] Someone with access should really go through those things, and clear out all the ones that have now been rendered(ahem) obsolete. Or, someone could just leave it as is, disable it and forget about it because sourceforge's bug tracking system sucks. [1] [1] This is strictly my own personal opinion, and particularly as applies to large projects such as XFree86/DRI/etc. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: XFree86 bugzilla available
On Wed, 19 Mar 2003, Philip Brown wrote: [...] The sourceforge bug tracker is a broken pos. Yet tens, if not hundreds, of people seem to have reported bugs successfully with it against dri. Millions could report bugs using it potentially. That doesn't make it a good tool, nor does it make it one that is well suited to the specific task of tracking bugs for the DRI project. The DRI developers clearly think that it is crap, and that is the bottom line really, regardless of what anyone else thinks. I just happen to agree with them. ;o) Even if the decision stands to no longer field new bugs there, it would still be nice if someone cleaned out the bugs there that are no longer relevant. Feel free. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: XFree86 bugzilla available
On Wed, 19 Mar 2003, [iso-8859-15] José Fonseca wrote: I know that the current policy on DRI is to post bugs on dri-users or dri-devel, but with XFree86 having a bug database is inevitable that people will eventually post bugs there too. Therefore what's the possibility of: - Setting up a general owner for DRI bugs, which probably would be [EMAIL PROTECTED] - automatically set the owner of DRI bugs, e.g., by the users adding a DRI keyword, or associating the XFree86 Server-DRI extension component. - Add the possibility to add comments to bugs via e-mail. Bugzilla requires a valid authenticated login. Not possible to do that with email-bugzilla at least currently. Basically I would like to be possible that: - An user adds a bug concerning DRI - The owner is (either manually or automatically) set to [EMAIL PROTECTED], which receives the bug - Any developer on the dri-devel list which has an account on XFree86 Bugzilla can reply and that comment is added to the bug database. Click on the URL in the bugzilla email, the bug comes up, and you can enter a comment directly into bugzilla. Even pine can do this easily. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: dri driver features page - radeon_naming
On Thu, 13 Mar 2003, Smitty wrote: My Radeon DDR VIVO identified itself (under windows) as a 7200... My Radeon 32MB SDR identifies itself (under windows) as a 7200... That's because the video drivers have had the PCI ID to name mappings changed from Radeon xxx SDR/DDR to Radeon 7200. To my knowledge, it is impossible to distinguish an original Radeon 32/64 SDR/DDR card from a Radeon 7200 card, as all that was changed is the marketing name on the box, and the name mapping in the video driver, etc. If they changed the subdevice ID of the 7200, or bumped the chip revision, then they might be able to be distinguished, however I'm not sure it matters since programatically they're identical. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Corrupted textures on 64bit tuxracer
On Tue, 11 Mar 2003, Dave Jones wrote: On x86_64 (probably any 64bit arch also, but I haven't tested ia64 or alpha yet), tuxracer experiences texture corruption on ice patches and the sides of some hills. This is occurs on the very first race, so it's not hard to reproduce. AS you're gliding along, the grey patch approaches and flickers terribly, but the portions that are white snow seem to work fine. Wierd. I used a radeon 7500 to develop the x86-64 agpgart code, _and_ I used tuxracer almost exclusively to test it, and hadn't noticed any problems. I'll upgrade X to our latest beta rpm in a while, and see if I can reproduce here, as its been a while since I tested it (definitly before 4.3.0 came out). It does appear to be TCL related, so older X servers probably wouldn't show it. Just wondering if anyone else experiences this on 64bit archs with tuxracer to help determine if it might be a bug in the game, or a bug on the X side of things. It sounds like a DRI regression, although it could also be something as subtle as toolchain problems. During early agpgart development, broken gcc's made some really wacky effects happen in tuxracer 8-) With the environment variable set as Michel suggested, the main problem disappears. The other 'problem' I saw seems to just be a visual effect rather than a bug. I don't generally run tuxracer ever, so I never really noticed it before. ;o) I think this can be written off as a tuxracer bug now. Thanks. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: patch for function naming consistency
On Wed, 12 Mar 2003, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. and mainly processes the DRI related driver options. Consistency is a Good Thing. It is nice and easy to do grep RADEONDRI tags to get a list of all DRI-related functions for radeon. [The fact that you can get more complicated with grep RADEON | grep DRI should not excuse the lack of consistency in naming] So RADEONPreInitDRI() doesnt actually do any rendering; So what. It is still DRI related. I think you're looking at function naming from a point of view of what all functions contain the 3 letters 'DRI' grouped together in the function name and wanting to change the name of RADEONPreInitDRI() because it doesn't match the others, rather than looking at the logical grouping of where the function exists now. I agree with Michel and think it is properly named as is, and in the proper location. What is the function classification based on? Is it based on performing a PreInit operation, or is it a DRI function that does preinit? I see it as the former as it is called from RadeonPreInit. IMHO, the names of functions and the file they are located in should be based on the functionality that they are providing, and should be grouped based on similar functionality and not based on similarities in portions of their names. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: patch for function naming consistency
On Wed, 12 Mar 2003, Philip Brown wrote: [] IMHO, the names of functions and the file they are located in should be based on the functionality that they are providing, and should be grouped based on similar functionality and not based on similarities in portions of their names. I agree with that sentiment 100%. Which is why when I see the function in question, as providing a DRI-specific function that does not *exist* if DRI is not compiled in, it seems straightforward to me that as such, it should have a DRI-oriented name, and belongs in radeon_dri.c With several people in disagreement with you though, I guess it might be a decision perhaps that should fall more into the lap of the driver maintainer or project lead or somesuch. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: patch for function naming consistency
On Wed, 12 Mar 2003, Keith Whitwell wrote: With several people in disagreement with you though, I guess it might be a decision perhaps that should fall more into the lap of the driver maintainer or project lead or somesuch. Well, I didn't have much to do with this code when it was written, but I'm happy for it to stay where it is and as it is named for now. If someone wanted to take on a bigger task of comprehensively spring-cleaning the radeon 2d driver, that might be interesting, but renaming moving that one function won't do anything to make the driver easier to navigate. Agreed. Also, there are IMHO large enough portions of code that are common to both the r128 and radeon driver at least, which could be moved to a common shared file. Unless it's objected to, I'll be investigating something like that in the future. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: dri driver features page - radeon_naming
On Thu, 13 Mar 2003, Ian Molton wrote: 7200 aka Radeon 64 DDR, is the type and speed of the memory, and that the TCL unit is somehow disabled via software. 7200 is SDR. You sure about that? My Radeon DDR VIVO identified itself (under windows) as a 7200... The original Radeon R100 chip was released in various products with different memory configurations. I believe all 4 of the following were shipped products: Radeon 32 SDR Radeon 32 DDR Radeon 64 SDR Radeon 64 DDR Also VIVO and AiW variants of the above. Every single board I've personally encountered all used the same Radeon chip, which is PCI ID: 1002:5144 aka. Radeon R100 QD. Some of these board variants were later discontinued, while others were rebranded as Radeon 7200. The Radeon 7200 is merely a new cosmetic name for the existing boards, however the chips are the same. Depending on how new or old your Windows (or XFree86) drivers are, any of the above cards will be detected as either Radeon QD or Radeon 7200. They are all one and the same however, just with different memory configurations. The Radeon QD chip supports TCL in hardware, and it works in XFree86 using the Radeon TCL code on all of them (since they're all the same chip). There was also another card which was called ATI Radeon LE which was made by 3rd party for the Asian market (according to an FAQ which may or may not still be on ATI's website). This card was a slower clocked card, which was intended as a lower priced Light Edition for that particular market and it is claimed to not have the hardware TCL unit. However, the card identifies itself also as a Radeon QD which we of course know does have the hardware TCL unit. I have never actually used or seen one of these in person, but I do know people who have had them, and have used the TCL features on the hardware in Windows (aparently hacking some registry settings), although I don't know anyone whom has used TCL on them in Linux. I presume that the card's BIOS disables the TCL unit (or perhaps just doesn't enable it) at POST, and so the Windows drivers aren't able to use it - or perhaps it is entirely a driver/registry thing. Not entirely sure, as I've never personally touched one. I do know however that all boards containing the Radeon QD chip do in fact have a useable TCL unit on them. Hope this helps to clarify the R100 line a bit. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Corrupted textures on 64bit tuxracer
On x86_64 (probably any 64bit arch also, but I haven't tested ia64 or alpha yet), tuxracer experiences texture corruption on ice patches and the sides of some hills. This is occurs on the very first race, so it's not hard to reproduce. AS you're gliding along, the grey patch approaches and flickers terribly, but the portions that are white snow seem to work fine. This is using XFree86 4.3.0 on a Radeon 7500 under a 64bit kernel with 64bit X. Everything is stable (doesn't crash), just the graphic glitches described above. Just wondering if anyone else experiences this on 64bit archs with tuxracer to help determine if it might be a bug in the game, or a bug on the X side of things. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: dri driver features page
On 9 Mar 2003, Michel Dänzer wrote: * 7X00 denotes a R100 based card. Should be removed, as Radeon 7000, is RV100, not R100. And what's the difference between the two, in particular as far as the drivers are concerned? :) My point is to provide documentation that is technically accurate as per ATI specifications, not bend them on a whim. Radeon VE, is Radeon RV100, regardless of wether the chip works like a R100 as far as DRI is concerned or not. Why make confusion? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon Depth buffer
On Fri, 7 Mar 2003, Ian Romanick wrote:
I was looking at the source for the radeon driver and noticed that the
depth buffer is always set to 32 bits if a 24 bpp color depth is
selected. Is this a hardware limitation, or might it be possible to
change it to 16 bpp?
There's two ways to do this. One would be to add an option to the X
server to select the depth-buffer size. Look in
programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c for how options
(like AGPSize) are handled. Basically, you'd add an entry like
{ OPTION_DEPTH_SIZE, DepthBits, OPTV_INTEGER, {0}, FALSE },
One of the following would be more consistent with option naming:
{ OPTION_DEPTH_SIZE, DepthSize, OPTV_INTEGER, {0}, FALSE },
{ OPTION_DEPTH_BUFFER_SIZE, DepthBufferSize, OPTV_INTEGER, {0}, FALSE },
Just a suggestion.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Radeon Depth buffer
On Sat, 8 Mar 2003, Ian Romanick wrote:
{ OPTION_DEPTH_SIZE, DepthSize, OPTV_INTEGER, {0}, FALSE },
{ OPTION_DEPTH_BUFFER_SIZE, DepthBufferSize, OPTV_INTEGER, {0}, FALSE },
Just a suggestion.
I had thought about that. The problem is that seems to imply setting
the size of the buffer, not the size of each element in the buffer. I
got to thinking about it last night, and now I have a different idea.
How about something like this?
{ OPTION_DEPTH_SIZE, ZBufferFormat, OPTV_ANYSTR, {0}, FALSE },
The existing options seem to follow the naming pattern of having
the macro named the same thing as the config file option, only
uppercased with word breaks turned into underscores, so if you
choose the config file option ZBufferFormat, then it would
be consistent to call it OPTION_Z_BUFFER_FORMAT IMHO.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Number Nine Revolution IV - DRI?
On Tue, 4 Mar 2003, Ian Romanick wrote: Is anyone interested in developing OpenGL DRI drivers for this card? If anyone is, I would be willing to pay for drivers - on the condition that they are Open Sourced. Please contact me for further information or questions. Is there any reason why you have to have support for that card? AFAIK, there is no documentation available for that card, and the company that made the chip no longer exists (at least not in its previous form). Not only that, there are MUCH better cards available for PCI and AGP that perform many orders of magnitude better. I seem to remember that this card can't even play the original GLQuake at a decent frame rate. Not to mention that the amount of money that would be required to pay to have the work done, would more than likely exceed the cost to replace the card(s) with newer hardware that is already supported by DRI. Unless someone has 1000 of these cards in a lab or somesuch perhaps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Number Nine Revolution IV - DRI?
On Tue, 4 Mar 2003, Carlos Noguera wrote: Is there any reason why you have to have support for that card? AFAIK, there is no documentation available for that card, and the company that made the chip no longer exists (at least not in its previous form). Not only that, there are MUCH better cards available for PCI and AGP that perform many orders of magnitude better. I seem to remember that this card can't even play the original GLQuake at a decent frame rate. I don't *need* DRI/OpenGL support for the card, but it would be incredibly nice to have it. Right now it is in my current setup, driving my SGI 1600SW flat panel and is the only AGP card that will drive that monitor without using SGI's Multilink Adapter (expensive, $450+ on eBay). It's an excellent display, and has Xfree support, so I am not really about to part with it. The 1600SW is hands down the best flat panel at an affordable price that I have seen. That being said, I thought this might be a nice challenge to a developer, help someone make some money, get me OpenGL (not looking for a gaming card anyway...), AND give back to the community all at once. Certainly an admirable offering. ;o) Not to discourage you, but just speaking of the likely reality that the cost of a brand new card, including that $450 Ebay gizmo on top of it, would more than likely be several thousand dollars cheaper than paying a developer to write drivers for an ancient video card from a company that doesn't exist anymore, and do so without hardware specifications. In contrast, there are several people working on ATI Mach64 3D support right now, whom do have the specifications for the hardware, as well as prior source code to use as a basis (Utah-GLX), and with help/support from other developers whom have worked on the hardware before, including tips from ATI. This project AFAIK is coming along nicely, and will hopefully be in a future X release. To attempt to do the same thing, for a card that barely nobody uses anymore, and without docs, or access to people familiar with the hardware, is extremely an unlikely thing to happen from anyone volunteer or otherwise. ;o) Even if you had $1 to put up for driver development, I doubt anything would come out of it in the end. Again.. not to discourage your effort. Just trying to provide what I believe to be a realistic expectation right now all things considered. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: voodoo specs
On 4 Mar 2003, Tom Hosiawa wrote: People have been mentioning the Voodoo specs are available but I've googled for them and found nothing, anybody know where they are??? http://www.medex.hu/~danthe/tdfx -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI? - why no one plays with Glide3. - documentation.
On Mon, 3 Mar 2003, Smitty wrote: I'd love to see more vendors providing specs, and doing so more openly, and preferably without NDAs. Ragging on vendors who do permit access to docs under NDA to people of their choosing, for not providing them to the world, is more likely to dry up access to specs for _EVERYONE_, and make binary only drivers the only way of getting modern hardware to work. In other words, I believe that whining about these certain realities, is equivalent to shooting one's self in the foot. Mike you're quite the downer at the moment, been a rough weekend? g Neither really. ;o) I'm just expressing my opinion on how things are, and what we can realistically expect now, and in the near future, at least from my perspective. I might not be 100% correct, but it's how I see things from my current viewpoint anyway. I couldn't care two hoots about whether or not ATI sits on the hardware documentation or starts distributing it to univertsities as teching aids. What I'm saying is that if they'd decide gee this document can be released without problem, along with this pile over here and this lot over here can probably be released for use only for writing OSS drivers then they should go ahead and do it. Absolutely. I think they'd (any vendor, not just ATI) do that if they really wanted to do that. I think the fact that some vendors do not do that is indicative that they don't want to do that however, or they would. ;o) It would make life a lot simpler for all concerned. Why should people have to fight to get documentation when ATI is in reality quite happy to give out certain docs, but because they have ceated an awkward process. I don't see it as a fight at all. Aside from the very few vendors who have publically released documentation (such as 3Dfx Voodoo 3, some older Intel docs, etc.), ATI is one of the vendors who provides docs to more people under NDA than any of the other vendors, with the exception of the cards mentioned above and some other older things here and there. In other words, if the alternative to a vendors docs under NDA, is no docs at all from the vendor, I don't think we should complain. At the end of the day an NDA isn't much protection, eventually the doc will fall into the hands of someone they don't want it to, whether someone has to steal it off someone who has signed a NDA, find it in the trash, bribe the night staff. Well, if people do not honour the NDAs that vendors give, it is a no brainer what will happen. If someone leaks documentation and breaks the NDA and it gets back to the vendor, the vendor is most likely just going to do one of: 1) Not provide documentation to people anymore period 2) Make the NDA more restrictive and provide documentation to less people 3) Provide watermarked docs under NDA to individuals. If docs leak, they can then sue the person who leaked them, as it is obvious due to the watermarking 4) Force developers to work right in the vendor's headquarters in a monitored room with access to docs that don't leave the premises (such as some of the Serverworks IDE work, etc.) It pretty much is an all or nothing approach. If they're prepared to release docs to members of TG, why don't they release them to TG directly? I really don't understand your point here. You are suggesting that ATI release docs to TG, and then let TG decide who gets them and who does not get them. ATI is capable of deciding who they want having their docs, and if they wanted TG to be the people to decide that, they would ask TG to do that. The fact that that has not taken place means that they are capable of deciding this on their own, and that that is not an option that they consider doing. I don't see the point of it anyway. What I was doing was putting forward a suggestion that TG may be able to get docs out of ATI easier (without screwing over ATI in the preocess). And my suggestion, is that if ATI wanted docs to go into the hands of random open source developers through TG, that they would themselves just give docs to those random open source developers, which is the way it is now. Developers get the docs from ATI, or they do not get the docs from ATI. I completely fail to see how/why/what TG has anything to do with this whatsoever. It was just a suggestion, maybe after I learn C I'll care, and argue my points with a lot more conviction. If you do not know C, the documentation would be useless to you in any case. It always seems to be the people who don't even know how to write helloworld.c that are the ones who complain about a vendor like ATI not providing them with hardware documentation that they couldn't do anything but make paper airplanes out of anyway. $0.02 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome
[Dri-devel] Re: future of DRI? - why no one plays with Glide3. - documentation.
On Sun, 2 Mar 2003, Smitty wrote: OK but here is my take on it, people will work on what they are interested in, so if someone wants to work on R128 and ATI does give out docs for that chip then they should give it to him. Whats the chance of ATI delegating some of this function to TG, ie just give all their hardware programmers guides etc that they are willing to let people see to TG with the understanding that TG only allow people who should see them to get hold of them. I think ATI is more than capable of determining who the are and are not willing to provide their hardware specifications to. I of course am not an ATI employee, and I do not know what their detailed reasoning is for access to their hardware specifications, nor do I care really, it's their documentation and they've got their own right to decide who gets what, and under what circumstances. Surely TG can respond quicker than a juggernaut like ATI, and then Jon Smirl would have got his docs already and made some progress. I don't think response time is an issue at all. This also makes sense in terms of concentrating development of OSS 3D drivers, allowing for higher productivity through division of labour, knowledge concentration, etc, rather than scattering the docs thinly accross the world to individuals. It doesn't compel those who have no interest in DRI but it sure helps those who do. It's a no brainer that the more widely available hardware docs are for any hardware, the more likelyhood of them being put to use by one or more people in the OSS community. That isn't a debateable topic I don't think. This whole issue however has nothing to do with who is the arbiter of access to vendor foo's documentation. Any particular vendor may or may not permit access to some/all/none of their documentation either freely and publically, or via NDA to specific individuals under whatever criterion they wish to decide upon. A bunch of people whining on a mailing list is not going to change that at all. In general, someone who goes ahead and works on the code and makes improvements WITHOUT a vendor's documentation generally has a better chance at actually getting it. Those who do nothing but whine on mailing lists that they can't do work on the code because they don't have the docs, are more likely to never see them. I don't think that any vendor is planning on providing hardware documentation widespread or to specific individuals based on a popular vote of some mailing list. There are certain realities that people must learn to accept and to deal with, and one of them is that some video hardware vendors do not want to provide any access to their hardware specifications at all. Others don't want their documentation widespread and public for whatever reasons they may have (none of our business really IMHO), but they may want to support the open source community nonetheless, and so they provide access to their documentation under an NDA agreement that they are comfortable with. It allows them to protect whatever it is they're wanting to protect, and it allows open source progress to be made as well. We're lucky to get specifications from any vendor who is willing to provide them to us under _ANY_ terms. I'd love to see more vendors providing specs, and doing so more openly, and preferably without NDAs. Ragging on vendors who do permit access to docs under NDA to people of their choosing, for not providing them to the world, is more likely to dry up access to specs for _EVERYONE_, and make binary only drivers the only way of getting modern hardware to work. In other words, I believe that whining about these certain realities, is equivalent to shooting one's self in the foot. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI?
On Fri, 28 Feb 2003, David Bronaugh wrote: NVIDIA already has their own cross-platform low level driver, with a cross-platform 3d API. It's their UDI, Unified Driver Interface, or something like that. So if they switched to using DRI, they would then be looking at rewriting their own crossplatform(?) opengl implementation that currently nicely slots onto their UDI. Has anyone put any thought into a 'migration' kit of sorts for DRI, so that IHVs can easily port their Windows drivers to DRI? How would that benefit the open source DRI project? By steering volunteer resources from working on open source code, to having volunteer resources working on implementing code that makes it even easier for binary only drivers to exist, thus making the DRI project irrelevant? Sorry, but hardware vendors aren't even interested in this so it would be pointless. I highly doubt that any unpaid volunteers are anxious to contribute to making the project irrelevant, and I highly doubt anyone is out there ready to pay to have something like that done either. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003, Smitty wrote: The 3Dfx Voodoo 3 and Banshee specs are available, as are docs for other 3D hardware. Who is working on that right now? 3Dfx released the source code of Glide3 for example. I dont think a single line of code has been written for Glide3 for 2 years now. Probably because, 3DFX is dead, I completely realize that 3Dfx is dead. My point is that even when they were alive still at the end, there wasn't much going on with the 3Dfx drivers. a V3 gets smacked around by a TNT2, Not with open source drivers it doesn't. Glide is not neccessary if you have OpenGL or DirectX, and Glide is low level 3dfx only. I'm also well aware of that. A useless API for old and slow not to mention dead technology. Yes, it is. But you missed my point. The point being that code exists and nobody is hacking on it. I'm not *blaming* anyone. Volunteers work on what volunteers are interested in working on. That's obviously not Glide3. Point is, there is code and docs that have been available to people that have not seen much contributions at all except by funded development. Look at the Intel i8x0 driver for example. The Intel specs are publically available, and Intel funds development of the driver. The hardware is readily available too. Yet there is not any major contributions to the code at all other than what is produced by funded development. This is hardware that is brand new, and by a company that is not dead. Forgive my bad example of choosing 3Dfx and Glide3. Which is probably why Molton is trying to instigate a divorce from Glide for the V3. I certainly support that move. Anholt was working on Glide3 recently a bit as well. I dunno how far he got, but I've been meaning to ask. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: future of DRI? - why no one plays with Glide3.
On Sat, 1 Mar 2003, Jon Smirl wrote: X has served us well for a long time but I just don't think it is sufficient to be the standard video platform for desktop Linux over the next ten years. We're not going to replace X overnight, but we need a path to slowly evolve it. I am amazed at the rate of change in the kernel, but X hardly seems to change at all. How can we speed things up? I believe it can be done by creating an X devlopment community/environment that is more conducive to future progress, and more open, accepting, and encouraging of new developers. The DRI project IMHO works pretty good in this aspect for ages now. For me, a layered approach where each piece can be compiled, used and tested independently would make X much more manageable. Something like this: Kernel level - fusion of DRM and FB, libDRM OpenGL - Mesa + DRI Xserver rest of X I'm sure people with more experience on X can divide it in a better way, but the key is in dividing it into smaller, more digestible chunks. These layers need to build and run independently. I can't agree more. I think X should be broken into several pieces personally that are independant of each other. The drivers should be decoupled from the huge monolithic sources IMHO, and built separately against a DDK of some kind. Not unlike the existing XFree86 sdk that I don't believe anyone uses currently. I'm investigating this currently in my tinkerings. I'd like to split up X sources sometime in the future into at least: 1) fonts 2) docs 3) video drivers 4) various applications not needed at X server build/install time 5) X server and everything else That's just phase 1 idea. I think it oculd be broken down much finer than that. The benefits IMHO would be large. The DRI tree has close to 10,000 files in it right now and DRI isn't even a complete X tree. That's an awful lot of code to read and understand as a single package. Agreed. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI?
of those reasons result in me thinking any of these vendors doubts the open source community is capable of hacking on source code. I would bet money, that the number 1, 2, and 3 reasons are entirely legal reasons surrounding intellectual property and other issues. While I totally am on the side of the fence that would love to see source code released of such drivers from _all_ vendors, I don't expect them to fully release the code of their drivers as I understand the legal and some other aspects. At least ATI contributes both source code and specifications to the open source community, and Nvidia contributes largely to the 2D only nv driver even though they do not providing hardware specs. Over time perhaps more and more will be released from different vendors. Time will tell I guess. One thing is certain though, and that is that no amount of community begging, petitioning, and other similar requests are going to get hardware companies to violate intellectual property laws just to oil a squeaky wheel. Instead, lets thank them for what they do give us, and politely request things of them that are realistically something they might be willing to, and legally able to provide us in the future, rather than a nonrealistic white card, which they're not likely to be legally able to do. Just my thoughts. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: future of DRI?
On Fri, 28 Feb 2003, Daniel Vogel wrote: Does DRI have a future with neither NVIDIA nor ATI participating? Are people actually talking to them about why they don't use it and what has to be done to remedy this fact? Shouldn't this be a top priority? To clarify: I meant what has to be done to make DRI (direct rendering *infrastructure*) attractive for IHVs. I didn't mean to imply what has to be done to get NVIDIA or ATI to release open source drivers and whatnot. The open source/ closed source discussion has been beaten to death and is irrelevant to this thread. My point was/is that without NVIDIA or ATI using the DRI infrastructure it is doomed to fail. Well... for starters ATI *is* using the DRI infrastructure. Does that mean that you think DRI is doomed to success now? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: future of DRI?
it is fantastic too. The Mach64 project, talk of Savage driver, and others on the way for older hardware. I just don't think it is realistic to expect that source code is going to materialize merely because specifications are made available. The 3Dfx Voodoo 3 and Banshee specs are available, as are docs for other 3D hardware. Who is working on that right now? 3Dfx released the source code of Glide3 for example. I dont think a single line of code has been written for Glide3 for 2 years now. Don't get me wrong here, I want DRI to succeed, and to be as open source as possible. But I think people need to be realistic about it and get off the fantasy clouds they're living in. My general experience of seeing people ask for specifications for various hardware, more times than not the person does nothing with them, or they fix one bug that bothered them then go away. That's either with specs that are open already, or with specs that they were able to convince a vendor to give to them. It'd be great if specs were all opened, but I don't think that there will be 100's of developers standing in line to hack on code if they were published on tomorrow's slashdot front page. There would be a very small handful. And hopefully they'd put together a successful project around it, but it wouldn't happen very quickly IMHO. Not without funding. 2) ATI could shift resources and contribute to the DRI code base instead of working on their own. Let me play devils advocate... What would they get out of it? 3) ATI can license their patents for royalty free use when developing drivers for their hardware. Other uses would require fees, like the new W3C patent position. I'm not talking about ATI's patents. I'm talking about other company's patents to which ATI may have licensed perhaps to use in their own hardware or software. They may not have legal rights to divulge this information. I fully believe that vendors can benefit the most from having open source drivers and specifications. I do not however believe that if a vendor releases specs or source that it will result in an overnight sensation of a stampede of new developers entering the foray. I also understand the various complex webs of legal issues such vendors may face due to licensing of patents, cross licensing agreements and other legal issues, and I respect their positions even though it would please me greatly more than anything to see all specs and sources opened up. Someone should really turn this topic into an FAQ we can point people to every 3-4 weeks when the topic comes up again. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: future of DRI?
On Fri, 28 Feb 2003, Daniel Vogel wrote: Fragmention still isn't good, which brings me back to my original question whether folks are talking to NVIDIA why they aren't using the DRI framework. I'm sure if Nvidia wanted to use DRI they would do so. What benefit would there be to Nvidia really of ditching their existing infrastructure which is closed source, and switching both their kernel side and userland side code to closed source code which uses the DRI infrastructure? Their code is also shared between Windows and I believe Macintosh, and DRI is not available on those platforms. I don't see exactly what you mean by fragmentation. 2 vendors using closed source code aren't fragmenting anything except for their own internal interests. The drivers are a black box really, and could be using any kind of interface, be it DRI, or some proprietary solution. It neither helps nor hinders the DRI project really. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Using DRI to implement 2D X drivers
On Thu, 27 Feb 2003, Philip Brown wrote: If 3D isn't important to a desktop, then why are my windows stacked on top of each other? Why do my buttons depress and my windows look like they have raised borders? Edit boxes have shadows and menus look like they raise when the mouse if over them. Right now we are going through a lot of effort to simulate 3D. I'm using fvwm. The borders are simulated 3d using very LITTLE effort. Having it done through opengl would probably increase the amount of complexity and whatnot considerably, I would guess. Sure, I could have smooth color gradients, fading, even animated borders... but I dont WANT them. That distracts me from what's actually going on in the window itself. I could care less about the borders. That's not a problem either. It just means that you are one of the people who would continue to use fvwm. Other people, having different individual preferences may however differ with what they would like to have. I too am somewhat of a minimalist when it comes to eye candy in the GUI, but I realize and understand the importance of eye candy to the masses of computer users out there. If someone wants to got ahead and implement those features, sobeit. None of us have to use them if we don't want to. It at least provides those who do want them, with the opportunity to have them. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Lock problem with Radeon DRI
On Tue, 18 Feb 2003, Martin Spott wrote: Where did you take the DRM sources from ? I usually take the source for the DRM module from the same DRI CVS tree I use to build the whole DRI thing, Mike Harris builds in Red Hat beta and in rawhide It appears to me that the kernel modules of Mike's build do not differ from XFree86 4.2.99.901 - at least he didn't include any additional patches that thouch the kernel modules. I have the impression he also did not include any patches that touch the Radeon driver in a way that might prevent from lockups. Just to be clear here. I do not build kernel DRM modules - ever. I do not package kernel DRM modules - ever. I take kernel DRM and pass it to arjan/alan occasionally, but I do not build DRM nor ship it to anyone, and I never have. So, there is no Mike's DRM. So are we going to see XFree86-4.3.0 with broken Radeon DRI drivers ? I do not decide what DRM code is used in DRI-CVS, nor in XFree86-CVS, nor in the Red Hat kernel, Linus' kernel, Alan's -ac patches, or any other place. I package up XFree86 itself, not the kernel. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: DRI Mailing list maintanence / maintaner
On Sat, 15 Feb 2003, D. Hageman wrote: I think spam filtering for dri-devel and dri-users would be a good solution -- IMO, that would be better than moderation. For dri-patches, the Reply-To is dri-devel. I'd rather have just commit messages and nothing else on dri-patches. Any comments/replies to specific patches, or posts dealing with CVS should go to dri-devel anyway. That's why I suggested limiting just dri-patches to sourceforge addresses. I have only been glancing at this thread, but basically it comes down to this - If the spam bothers you that much setup spam filtering on your personal machine and be done with it. We waste more time and bandwidth talking about what should be done (with the list) then actually doing what really should be done (with dri). Just my thoughts ... As stated in my previous mail, I do use spamassassin, and as such I do not have a problem with spam. If you're not interested in the discussion on despamming, then simply hit DEL on the messages that do not interest you, and you'll lose no time at all. If other people wish to discuss it, they can, and will. Freedom of speech. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: DRI Mailing list maintanence / maintaner
On Mon, 17 Feb 2003, D. Hageman wrote: As stated in my previous mail, I do use spamassassin, and as such I do not have a problem with spam. If you're not interested in the discussion on despamming, then simply hit DEL on the messages that do not interest you, and you'll lose no time at all. If other people wish to discuss it, they can, and will. Freedom of speech. Please - what one minute here! I hold the freedom of speech very close to my heart for specific reasons I won't go into. What I wrote above in no way indicates that I want such a freedom restricted or otherwise removed. What I did write above is an indication of my insight into the problem: 1) Moderating a list restricts the flow of information (thus in some way can be viewed as a restriction of speech ... see above). 2) Limiting the mailing list interaction via mail addresses limits the flow of information (thus in some way can be viewed as a restriction of speech ... see above). 3) Implementing a mailing list wide spam filter can remove potentially beneficial e-mails (thus in some way can be viewed as a restriction of speech ... see above Besides I know it will never happen unless we take the lists off of sourceforge and host them else where ... or so the little birds tell me). Stating that ... too much energy has already been wasted ... on spinning wheels. My point, is that freedom of speech grants me, and anyone else on this mailing list the right to discuss the issue we are discussing. You have the right to use procmail to filter out the discussion when you are no longer interested in reading it. We'll keep the Subject line the same for your benefit. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: ATI reference drivers
On Thu, 13 Feb 2003, Alexander Stohr wrote: development for the Linux platform has not stopped, surely not, it is just that there were no releases in the last two months or so. i have to admit that there were some problems as for any driver out there, but none was so fundamental serious that we felt it needed an instant driver update. I'm wondering - TransGaming sent in some feedback to ATI about these driver's use of the fs register, which conflicts with the Win32 threading model, replicated by Wine and WineX (TransGaming WineX is designed to run Windows games on Linux). Do you happen to know the status of this issue? WineX is clobbering a register that the OpenGL part of the driver has already sort of claimed? Then their software is sort of broken. ;-) I have never tried WineX myselves in recent times but i am confident that the next ATI Linux driver release will address that thing so that this conflict is solved. As I understand, the fs register is reserved for Wine/Winex usage, and the gs register is used by newer glibc for libpthread, and in the latest glibc for thread local storage (TLS), for threaded applications at least. Anything else using these registers is going to have problems. Nothing should be using fs or gs aside from the above. I've carbon copied Ulrich, Jakub and Arjan in case they'd like to add comments as well. Hope this helps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: mach64-0-0-6-branch
On Wed, 12 Feb 2003, Martin Spott wrote: Date: Wed, 12 Feb 2003 14:36:41 +0100 (CET) From: Martin Spott [EMAIL PROTECTED] To: [EMAIL PROTECTED] List-Id: dri-devel.lists.sourceforge.net Subject: Re: mach64-0-0-6-branch [...] Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. Could anyone tell me if I'll find recent GATOS stuff merged into the current XFree86-4.3 pre-releases ? I did not find the answer neither on the GATOS pages nor in the XFree86 CVS 'changes.html' document. I _did_ expect XFree86-4.3 to be 'up to date' with GATOS and would like to see some sort of proof - _before_ downloading tons of source code, No, GATOS wont be integrated into 4.3.0. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: ATI reference drivers
On Mon, 10 Feb 2003, Michael Born wrote: Please excuse my not very DRI related question. Is there an official statement from ATI regarding the product cycle of their binary 3D drivers for Linux x86? In an interview at www.sharkyextreme.com an ATI person stated that they will release 8-10 Windows driver over the year. Their Linux driver is dated 29th november 2002 and has a lot of problems as I read in the Suse mailing list. If there is no comment on the future support of this driver - it is worthless because nobody knows if the ATI hardware will ever be usable. Questions and comments pertaining to ATI's binary drivers don't really have a place here. Such comments should be directed to ATI's online feedback webpage near where you download the drivers themselves. While ATI's binary drivers use the DRI infrastructure, they are unrelated to the DRI project, and this mailing list. In other words, nobody hear can help you. I really would like to buy an ATI card (9100 or 9500), but with no driver support I'll have to stay with Nvidia cards. The Radeon 9000 is supported by DRI, and I just submitted a patch to XFree86 last week which got added to XFree86 CVS shortly after which adds support for the Radeon 9100, however it is not tested on actual Radeon 9100 hardware yet. The 9100 is a R200 board so it should work, but no promises. If nobody has done it already, I can bring the latest PCI ID changes over from XFree86 CVS head and commit them to DRI-CVS. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [patch] Yet another DMA buffer leak
On 8 Feb 2003, Michel Dänzer wrote: Found it. DRIVER_RELEASE in radeon.h has to call radeon_reclaim_buffers as the drm_drv.h template seems to expect DRIVER_RELEASE to handle this. DRIVER_RELEASE in i810.h does this too. The (1 line) patch is attached. Thanks for fixing yet another one Felix! Indeed, keep up the good work! :) Should this not be forwarded to [EMAIL PROTECTED] or [EMAIL PROTECTED] as well? It should get picked up from the mesa-4-0-4-branch, where I'll commit it shortly, as well as to the trunk. The cutoff date for XFree86 4.3.0 is today however, so if they do not sync with Mesa, the changes may not get into 4.3.0. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: different build options for alpha
On 7 Feb 2003, Michel Dänzer wrote: Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Yes. Applying it would be similar to adding the following to the trunk for x86: DefaultGcc2i386Opt -march=i686 -mcpu=i686 In other words, it would make the default build run only on EV56 Alpha machines or higher. There are a great many EV5 machines out there, and most people I encounter running Alpha (such as on #alpha on freenode) are using EV5 boxen. Please don't apply this to the default build, it is something that someone should add as an architecture customization IMHO. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: different build options for alpha
On 7 Feb 2003, Michel Dänzer wrote: Date: 07 Feb 2003 00:04:59 +0100 From: Michel Dänzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary==-VHm8nTy1q66jRspvQ0H6 List-Id: dri-devel.lists.sourceforge.net Subject: different build options for alpha Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Oops.. I misread your patch. It does -mcpu=ev56 and not -march=ev56, so it would still run on any alpha. My bad. As a total guess, most businesses probably have EV56 or higher in usage, however I'd also guess most hobbiests have EV5 machines, so choosing a default instruction scheduling that is representative of the majority out there would be tricky. I'm using EV67 here, so either will work for me. ;o) It might be best to stick with the lowest common denominator perhaps. TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: different build options for alpha
On 7 Feb 2003, Michel Dänzer wrote: Someone sent me this patch to build my Debian packages on alpha. Is there any reason not to apply it to the trunk? Oops.. I misread your patch. It does -mcpu=ev56 and not -march=ev56, so it would still run on any alpha. My bad. I think you still haven't looked at the patch carefully... there's been -mcpu=ev6 in there for as long as I remember, which breaks on the ev56 machine of the person who sent me that patch. I committed the solution discussed with Alan now. Gah.. typo.. my brain isn't with me today... -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: A question, about Rage128 and news in DRI
On Mon, 3 Feb 2003, Stefan Lange wrote: VIA/S3 has been contacted several times already, whether they'll allow the integration of S3TC-support in the DRI. Unfortunately they never answered. So it's not very likely that you'll S3TC in DRI in the near future. Things might change some time, if you're lucky, but I doubt it. If you update ut2k3 to the latest version you'll be able to play it even without S3TC-support, however. But I seriously doubt that you can play ut2k3 with a r128 anyway... UT2003 indeed would probably not run on an R128 in Windows well if at all. I doubt highly it would fare much better with DRI IMHO. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon PCI Fix
On Mon, 3 Feb 2003, Keith Whitwell wrote: please find attached a complete patch that allows pci Radeon cards to work with DRI. It was created against the DRI CVS xc branch/trunk. Thanks, I'll commit this unless someone else comes up with a better solution. Well, I'd like to at least understand why *two* reads are necessary. The first one to flush the ring buffer to the card prior to the COMMIT_RING(), then the second one to flush the RADEON_WRITE() inside COMMIT_RING() right away. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Configuration File Example.
On Thu, 30 Jan 2003, Smitty wrote: How about this for something which can be edited by a GUI program which can change the settings, and which I / you / world+dog can read, understand and edit easily in a text editor? GUI *and* CLI editable without having to squint at it. Anyone see any problems if so feel free to educate me. #No spaces except between the connfiguration option and the choice #The only configuration options are those in brackets #Explain how Global config is overwriten by Device which is overwritten #by Program. Global Begin Anisotrophic_texture_filtering(Y/N) Y Bilinear_filtering(Y/N) Y Trilinear_filtering(Y/N) Y AGP_speed(1/2/4/8) 1 End; Device 0 Begin AGP_speed(1/2/4/8) 2 End; Device 1 Begin AGP_speed(1/2/4/8) 4 End; Program Quake1 Begin Trilinear_filtering(Y/N) N Double_buffering(Y/N) Y End; Program UT Begin Trilinear_filtering(Y/N) N Double_buffering(Y/N) Y Vertical_sync(Y/N) Y End; 1) Requires special parser which is too syntax sensitive 2) Users editing the file could hose it rather easily compared to existing formats. For a new config file, I personally think it makes the most sense to use one of either: 1) XF86Config style file, and use libxf86config to parse it, possibly extending the lib slightly as needed. or 2) One of the XML-is-my-favourite TLA ideas Either one has a good arguement on both sides. Reinventing a new format though buys nothing. I'm of the faith that good GUI/TUI config tools should be handling everything for configuration. End user edited config files == bug reports out the wazoo. I'd prefer to not ship some specialized config format at all than to ship one that wasn't well thought out, and also keeps the principle of least surprise. KISS principle. Also, a bit of open source philosophy - reuse what exists already, don't reinvent. $0.02 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Version handshake problems?
On 12 Dec 2002, Michel Dänzer wrote: /proc/dri shows 0, 1 and 2. 0 - tdfx 0xe200 (The Matrox) ^^ tdfx == 3Dfx Voodoo 3/4/5 or banshee, it is not Matrox -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Keith Whitwell wrote: Right now for 2.4 I'm juggling too many conflicting balls, if its all in the DRM CVS then merging stuff added to DRM cvs is a real nobrainer, and since I can do it item by item as it changes its also easy to know when something bad happens. I've been looking at what's in 2.4 and it's quite divergent from what we've got on the trunk. It is pretty closely related to the xfree 4.2 code, though, and most of the changes seem to be in the 2.4 code. Are you proposing pulling the dri trunk code into 2.4? Is the DRI trunk compatible with XFree86 4.1.0, 4.2.0, 4.2.1, and current CVS XFree86? If so, and it is considered stable, which is what I presume by it being considered for 2.4.x integration, then it makes sense to me to do so. Backward compatibility with releases back at least as far as 4.1.0 is critically important though. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On 12 Dec 2002, Alan Cox wrote: Date: 12 Dec 2002 18:22:10 + From: Alan Cox [EMAIL PROTECTED] To: Alan Hourihane [EMAIL PROTECTED] Cc: D. Hageman [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Type: text/plain List-Id: dri-devel.lists.sourceforge.net Subject: Re: [Dri-devel] DRM Kernel Questions On Thu, 2002-12-12 at 12:40, Alan Hourihane wrote: The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them for things pci_alloc_consistent ? I don't know the answer to that, but it brought up a thought in my mind. DRM is supposed to be backward compatible currently as far back as 4.1.0. It would make the most sense to me then, to check all DRM changes into xf-4_2-branch, and xf-4_1-branch as soon as they're known to be stable and correct. This ensures that DRM is updated in all releases. The alternative is having people get a given X release, and then use the DRM from the most recent X release. Or should they be getting it from DRI-CVS instead? Or from kernel.org? A lot of confusion in DRMland... -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Alan Hourihane wrote: The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them for things pci_alloc_consistent ? No, nor does 4.2.1. Should anyone be using XFree86 CVS stable branch DRM nor trunk DRM then? I presume if bugfixes are not going into XFree86 CVS stable branches, that the DRM in there is snapshoted and then throwaway. Where should we be getting DRM from for our kernel, and where should we be sending bug fixes for DRM to? I'd like to have one single location, be it kernel.org, DRI-CVS, or XFree86.org to both get DRM from, and send in bugfixes for. I have been getting it from XFree86 CVS in the past, generally right after a merge, or when I spot drm changes in cvs-commits. Right now however, for both Red Hat kernels, and kernel.org kernels there is up to 2 levels of indirection between the kernel.org kernel updates and the DRM upstream source, and it seems also that many bugfixes also go through 2 or more levels of indirection. Where should all DRM bug fixes be sent? Right now if I've got a DRM bugfix hypothetically, I've got to send it to Arjan for inclusion in our kernel, then Alan or Marcelo for inclusion in the kernel.org kernel, and should probably have it sent to linux-kernel so other vendors are aware of it also, then dri-devel to make DRI developers aware of it for inclusion into DRI CVS too, as I understand nobody follows linux-kernel, and also to XFree86's patch queue. It's impossible to track all of that, and to track wether or not a given patch has actually been accepted in all of those locations and is applied or not. It's possible that one group of people may not apply the patch until it is accepted by group B or C, and that the submitter may be expected to monitor group B to see if they accept and apply it, and then again notify group A, C and D that the patch is applied, please apply it to your set too. As the number of patches goes up, and the number of releases of the kernel, XFree86, our distro, etc. it is impossible to keep track of it all. What I would like to see, is the DRI project, the XFree86 project, the Linux kernel folk all agree to one single unmistakeable official location for acquiring the current official stable kernel DRM source, and one single official location for submitting bug fixes, and then either: 1) That one location is responsible for pushing the fix out to whatever other places they feel are necessary or warranted. or 2) The various projects all pull the fixes in themselves from the one single central 'official' location, and if sent a fix from someone randomly, they automatically forward it on to the official location and not just apply it locally to their tree. That could be DRI-CVS, XFree86 CVS, or kernel.org. Also, it'd be prefered if that one official location would release versioned tarballs of the official DRM release, which would then be easier for people to manage what changed between different versions than tracking a given CVS head which may possibly become unstable at some times, etc. Right now, as it stands, I often get bug reports of DRI lockups and problems in our bugzilla, which upon deeper investigation turns out to be someone using a kernel.org kernel instead of our supplied kernel, and the DRM isn't new enough, or contains bugs that our kernel does not, and that DRI-CVS or XFree86 might not. We need... One DRM to rule them all, One developer to find them, One DRM to bring them all, And in the darkness find them. dodges tomatoes Yes, that was a lame attempt at humor. Seriously though, having 50 frayed trees of the same source code benefits nobody really, especially if various people consider different trees as authoritative/stable/official/whatever. As long as XFree86 / DRI Project / kernel.org each have their own DRM code, people will pull DRM from one of the three locations, and people will send bug reports, fixes, etc. to 3 locations. If each of those locations refuse to send patches on to the other locations, and expect the submitter to do it, the whole thing breaks down. What solutions do people think would be appropriate? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing
Re: [Dri-devel] Re: [Xpert]Re: Probable return of Radeon, R128XFree86 crash at VT switch
On Thu, 17 Oct 2002, Marc Aurele La France wrote: The problem WAS that this re-enabling did not always take place before Marc's changes, which is why we added the explicit call to do this. I've checked the code in current XFree86 CVS, but would very much like to know (just for interest's sake) WHERE exactly the PCI enable (or whatnot) is called from that re-enables bus mastering after a VT switch. The question on my, and David's, mind is whether or not bus mastering was enabled on server entry. I can't say for every reported case, but I can say that on the cases I examined personally, that the video hardware had Bus Mastering enabled prior to the X server being started (lspci -vvv), as well as while the X server was running. Switching to a VT and doing lspci -vvv then showed bus mastering disabled. I witnessed this on 3 different systems personally, and via testing feedback from various users got similar responses back. Not sure if all systems were this way, but some were at least. For the current CVS code, I don't know if the problem is present or not. I've disabled Charl's patch for now in order to have the stock code well tested. Our kernel hasn't been updated with the latest DRM source however, so testing hasn't begun yet. Sometime in the next couple weeks I'll likely have our kernel DRM updated, and bang on the Radeon a bit. If the problems recur, I'll try out Charl's patch again, and possibly do a debug session with Charl and MrCooper again if they're game. Has anyone else already tested it for hanging? TTYL -- Mike A. Harris --- This sf.net email is sponsored by: Access Your PC Securely with GoToMyPC. Try Free Now https://www.gotomypc.com/s/OSND/DD ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Ann: gcc-2.96 compiled snapshots available (I'm going tosmack redhat)
. Thanks, TTYL -- Mike A. Harris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Typo on http://dri.sourceforge.net/other/radeon_dri_features.html
There's a typo on the Radeon features webpage: http://dri.sourceforge.net/other/radeon_dri_features.html At the bottom it has IcDT Gatos Should be iDCT (Discreet Cosine Transform) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: The Radeon LE?
On Wed, 10 Jul 2002, Mike Mestnik wrote: Date: Wed, 10 Jul 2002 18:29:44 -0700 (PDT) From: Mike Mestnik [EMAIL PROTECTED] To: Stefan Lange [EMAIL PROTECTED], Adam Duck [EMAIL PROTECTED], Michal Kozlowski [EMAIL PROTECTED] Cc: lists.sourceforge.net dri-devel [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: dri-devel.lists.sourceforge.net Subject: Re: The Radeon LE? # # List of PCI ID's # # Maintained by Martin Mares [EMAIL PROTECTED] and other volunteers from the # Linux PCI ID's Project at http://pciids.sf.net/. New data are always # welcome (if they are accurate), we're eagerly expecting new entries, # so if you have anything to contribute, please visit the home page or # send a diff -u against the most recent pci.ids to [EMAIL PROTECTED] # # Daily snapshot on Tue 2002-07-09 10:00:05 # This isn't the only place to find PCI IDs but it seems to explain all the hardware I have. You can take a look at the list if you want, but there's not mention of a card maid by ATI with an LE in it's name. The name really isn't important it's the meaning behind the name. I've got a Radeon 7500 QW Product ID 0x5157, and I also have A Radeon QL Product ID 0x514C, I didn't look at the sub device to see if That was accurate. I would like to know what the Product ID of your Radeon LE card is and I'd like to add it to the data base. If it is 0x514C then where did you learn that it's also called an LE, I'm just curious? The Radeon LE, if I'm not mistaken, is the same PCI ID as the regular Radeon 64DDR hardware (0x5144), which is referred to as Radeon QD. I do not know of a way of distinguishing between a real Radeon 64DDR and an LE, or any of the other cards which use the 0x5144 chip. I presume you need to use the subvendor/subdevice ID, however nobody has bothered since they just work(TM). Please in the future make it clear what your talking about to avoid confusion, it seams to me that the LE's work while the QW's don't It could be that they have different Product IDs, or that they just need to be treated as if they did. Note also that ATI has not produced Radeon LE boards. These cards were produced aparently by a third party in the APAC region as low cost solutions for that region. ATI has a page on this on their website somewhere although I don't have the URL handy. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRM patch for i810/i830 memory allocation (fwd)
Please apply this to the DRI codebase. Also forwarding it to
XFree86.
--
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer Ontario, Canada, P6C 5B3
Red Hat Inc.
http://www.redhat.com ftp://people.redhat.com/mharris
-- Forwarded message --
Date: Tue, 9 Jul 2002 09:02:48 -0400
From: Arjan van de Ven [EMAIL PROTECTED]
To: Mike A. Harris [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Subject: DRM patch for i810/i830 memory allocation
Hi,
The patch below makes the i810 and i830 drm kernel
module use the PCI DMA mapping API instead of an
ad-hoc allocator for allocating the page that is used
to communicate between driver and card. The ad-hoc allocator doesn't
actually work well in practice (I get quite a few bugreports about it) and
the PCI DMA API should be used regardless (it actually works cross-platform)
Greetings,
Arjan van de Ven
diff -urN linux/drivers/char/drm.org/i810_dma.c linux/drivers/char/drm/i810_dma.c
--- linux/drivers/char/drm.org/i810_dma.c Fri Jul 5 16:12:21 2002
+++ linux/drivers/char/drm/i810_dma.c Fri Jul 5 17:15:08 2002
@@ -258,30 +258,6 @@
return retcode;
}
-static unsigned long i810_alloc_page(drm_device_t *dev)
-{
- unsigned long address;
-
- address = __get_free_page(GFP_KERNEL);
- if(address == 0UL)
- return 0;
-
- get_page(virt_to_page(address));
- LockPage(virt_to_page(address));
-
- return address;
-}
-
-static void i810_free_page(drm_device_t *dev, unsigned long page)
-{
- if (page) {
- struct page *p = virt_to_page(page);
- put_page(p);
- UnlockPage(p);
- free_page(page);
- }
-}
-
static int i810_dma_cleanup(drm_device_t *dev)
{
drm_device_dma_t *dma = dev-dma;
@@ -296,7 +272,8 @@
dev_priv-ring.Size);
}
if(dev_priv-hw_status_page != 0UL) {
- i810_free_page(dev, dev_priv-hw_status_page);
+ pci_free_consistent(dev-pdev, PAGE_SIZE,
+dev_priv-hw_status_page,
+ dev_priv-dma_status_page);
/* Need to rewrite hardware status page */
I810_WRITE(0x02080, 0x1000);
}
@@ -462,7 +439,8 @@
dev_priv-zi1 = init-depth_offset | init-pitch_bits;
/* Program Hardware Status Page */
- dev_priv-hw_status_page = i810_alloc_page(dev);
+ dev_priv-hw_status_page = pci_alloc_consistent(dev-pdev, PAGE_SIZE,
+ dev_priv-dma_status_page);
if(dev_priv-hw_status_page == 0UL) {
dev-dev_private = (void *)dev_priv;
i810_dma_cleanup(dev);
@@ -472,7 +450,7 @@
memset((void *) dev_priv-hw_status_page, 0, PAGE_SIZE);
DRM_DEBUG(hw status page @ %lx\n, dev_priv-hw_status_page);
- I810_WRITE(0x02080, virt_to_bus((void *)dev_priv-hw_status_page));
+ I810_WRITE(0x02080, dev_priv-dma_status_page);
DRM_DEBUG(Enabled hardware status page\n);
/* Now we need to init our freelist */
diff -urN linux/drivers/char/drm.org/i810_drv.h linux/drivers/char/drm/i810_drv.h
--- linux/drivers/char/drm.org/i810_drv.h Fri Jul 5 16:12:02 2002
+++ linux/drivers/char/drm/i810_drv.h Fri Jul 5 17:10:41 2002
@@ -63,6 +63,7 @@
unsigned long hw_status_page;
unsigned long counter;
+ dma_addr_t dma_status_page;
atomic_t flush_done;
wait_queue_head_t flush_queue; /* Processes waiting until flush*/
diff -u linux/drivers/char/drm.org/i830_dma.c linux/drivers/char/drm/i830_dma.c
--- linux/drivers/char/drm.org/i830_dma.c Sat Jul 6 11:57:25 2002
+++ linux/drivers/char/drm/i830_dma.c Sat Jul 6 15:18:14 2002
@@ -283,31 +283,6 @@
return retcode;
}
-static unsigned long i830_alloc_page(drm_device_t *dev)
-{
- unsigned long address;
-
- address = __get_free_page(GFP_KERNEL);
- if(address == 0UL)
- return 0;
-
- atomic_inc(virt_to_page(address)-count);
- set_bit(PG_locked, virt_to_page(address)-flags);
-
- return address;
-}
-
-static void i830_free_page(drm_device_t *dev, unsigned long addr)
-{
- if (addr) {
- struct page *page = virt_to_page(addr);
-
- put_page(page);
- UnlockPage(page);
- free_page(addr);
- }
-}
-
static int i830_dma_cleanup(drm_device_t *dev)
{
drm_device_dma_t *dma = dev-dma;
@@ -322,7 +297,8 @@
dev_priv-ring.Size);
}
if(dev_priv-hw_status_page != 0UL) {
- i830_free_page(dev, dev_priv-hw_status_page);
+ pci_free_consistent(dev-pdev, PAGE_SIZE
[Dri-devel] Re: IRC Meetings ML notification
On Tue, 9 Jul 2002, José Fonseca wrote: Date: Tue, 9 Jul 2002 22:09:58 +0100 From: José Fonseca [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: dri-devel.lists.sourceforge.net Subject: IRC Meetings ML notification First I would like to apoligize for missing the last two IRC meetings. There was no noble reason whatsoever - I completely forgot it. Although this is no excuse, I would like to request that a notification message is always sent to this mailing list - as it was often done -, even if it's sent just on the meeting start. Anyway, I'm going to see next week I don't forget it again (and with some luck even send the notification myself!) I've been on two week vacation, and haven't sent out any notices either. If someone would like to automate an email to this list every Monday, an hour or so before the meeting, that would probably be a good idea. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Compilation
On 23 Jun 2002, Marc Poulhiès wrote: Date: 23 Jun 2002 22:28:14 +0200 From: Marc Poulhiès [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: dri-devel.lists.sourceforge.net Subject: Compilation Hi! sorry if this question is very dumb, but i wanted to test the latest dri drivers for my ati radeon 8500 but they wont compile... Here are the messages i get: There are no Radeon 8500 DRI drivers. Not until October-December this year anyway (Q4/2002). You'll have to wait until then. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Default AGP mode
On Wed, 12 Jun 2002, David S. Miller wrote: From: Jeff Hartmann [EMAIL PROTECTED] Date: Wed, 12 Jun 2002 21:57:31 -0500 Actually, its most safe to default to AGP mode 1x. If we aren't switching modes correctly there is a bug in that agp driver, and I'd like to know about it. Try to enable 4X in BIOS of SiS Athlon chipset, startup X in default mode, SPLAT. This is a widely known problem and you aren't going to get all of the chipsets right in particular the AMD76x ones. I'd suggest rethinking the use 1X by default logic, it's wrong in half of the cases. Unforunately there is no real way to test if anything above AGP mode 1X works correctly. Defaulting to AGP mode 1X is the best option, since AGP mode 2X might cause the machine to lockup upon initiating a DMA request. Certain card/motherboard combinations just don't work above 1X. I totally disagree, you're locking up now on half the chipsets if the user enables anything other than 1X mode in his BIOS. The reason the machine locks up on 1X mode is for the same damn reasons, the driver isn't programming the chip correctly or we lack the workaround which in a manner of speaking is the same problem. Ben LaHaise suggested tonigth to me on IRC that perhaps we could read the AGP mode from the BIOS and set that by default, and also keep blacklist/whitelists in the drivers/whatever to deal with side cases or known bad combinations. That sounds good to me in theory, however I don't know how feasible it is in reality, so I thought I'd pass the idea on to you guys whom are obviously much more familiar with the intricacies of this stuff. Does this sound reasonable? Or are there factors which would make that overly difficult as well? It's a good idea to at least explore this problem domain a bit, and try to brainstorm it. It's just as frustrating for one group of 100 users to have slow 3D and not know much about reconfiguring it (or that they even can) as it would be to change things to default to faster, and lock up on other users systems. There's got to be a way we can make the situation better somehow. The more end user configuration we require, the more end users lose out, and the more complicated the whole system becomes. The more bug reports and problems, tech support, etc... Someone suggested to me setting AGPmode in Cards for different hardware, but I thought that was quite crack-rock'ish since you have no idea what mobo chipset is in use, etc. TIA -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Default AGP mode
On Wed, 12 Jun 2002, David S. Miller wrote: Basically, someone has asked for me to default AGPMode to 4 in our config file, which I thought was absolutely crazy. The claim is that AGP defaulted to 1x, but changing it to 4x sped things up dramatically. That is what lead me to believe that the default being used is not the BIOS setting. That's almost as stupid as the current situation which defaults to 1X AGP. I agree, defaulting to AGP 1x right now is just not the best thing to do anymore. All current generation hardware and even the last gen or two can do AGP 2x. Another known failure case (when user sets BIOS to 4X and X tries to use it's default of 1X) is ALI M1647 chipsets. That also hangs. Right. All of this points to using the BIOS supplied default as being the logical way to go. Is this information already available inside the X server? xf86GetAGPInfo() appears it might be what I'm looking for here. info-agp_mode Is this the right bits? Until we can be confident that every single AGP chipset is %100 done and has %100 of the workarounds, I'd highly suggest against trying to switch AGP modes by default. I agree. How about this scenario then: Any default is going to have certain failure cases. Lets make the default AGP mode the X server uses be the AGP mode that the BIOS has set. Whatever failure cases show up, we can blacklist and/or whitelist known good ones, etc. This makes autodetection and autoconfiguration all the simpler. Doing this with user initiated config tools IMHO is just a bad idea. I also think doing the BIOS AGPmode autodetect in a config tool, and setting AGPMode inside the X config file is bad because it assumes too much, and hard codes things at config time rather than autodetecting them at runtime. Change motherboards, you don't want problems to pop up if it can be avoided for example. To my knowledge only the ServerWorks AGP bits are a) written by the vendor b) have all the necessary errata workarounds. ServerWorks AGP was written by VA under contract with ServerWorks IIRC. I've got a Tyan 2567 motherboard with the ServerWorks HEsl on it personally. Unfortunately it only works in AGP 1x mode. AGP 2x is fried (or was last time I tried. Chipset/BIOS/implementation problems IMHO, not X bugs. Kimball Brown at ServerWorks was very helpful to me in getting AGP working at all on this thing though despite the faulty motherboard design and broken BIOS. It'd be nice to pull the needed info out of other vendors also. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Default AGP mode
On Thu, 13 Jun 2002, David S. Miller wrote: Date: Thu, 13 Jun 2002 00:53:16 -0700 (PDT) From: David S. Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Type: Text/Plain; charset=us-ascii Subject: Re: [Dri-devel] Default AGP mode From: Mike A. Harris [EMAIL PROTECTED] Date: Thu, 13 Jun 2002 02:58:53 -0400 (EDT) Ben LaHaise suggested tonigth to me on IRC that perhaps we could read the AGP mode from the BIOS and set that by default, and also keep blacklist/whitelists in the drivers/whatever to deal with side cases or known bad combinations. No need to read from the BIOS, just read the AGP registers. Oops, bad wording on my part.. I meant Read the BIOS configured AGP mode. I'll have a look at this tomorrow for sure and see if I can figure it out. Thanks again, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: tcl branch merge
On Tue, 11 Jun 2002, Keith Whitwell wrote: Date: Tue, 11 Jun 2002 10:56:16 +0100 From: Keith Whitwell [EMAIL PROTECTED] To: dri-devel [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed List-Id: dri-devel.lists.sourceforge.net Subject: tcl branch merge Although we still have a couple of bugs a lockup on the tcl branch, the situation is in general better than what's on the trunk I'd like to get that code merged now. This will also help get the 8500 branch started. Anyone with any objections should speak up now. For God sake, nobody speak up! ;o) -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Default AGP mode
It would appear that AGP mode 1x is used by default always unless the AGPmode option is specified in the config file. (Correct me if I'm not completely correct with that). I'm wondering if the default can be changed to be the fastest sane mode supported by the hardware and/or configured by the BIOS. I'm unfamiliar with any discussions that may have previously occured or the rationales behind the existing defaults. If possible I'd like to change the defaults to be more sane to modern hardware. Any comments? -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Default AGP mode
On Wed, 12 Jun 2002, David S. Miller wrote: Date: Wed, 12 Jun 2002 18:08:37 -0700 (PDT) From: David S. Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: Text/Plain; charset=us-ascii Subject: Re: [Dri-devel] Default AGP mode From: Mike A. Harris [EMAIL PROTECTED] Date: Wed, 12 Jun 2002 20:35:15 -0400 (EDT) It would appear that AGP mode 1x is used by default always unless the AGPmode option is specified in the config file. (Correct me if I'm not completely correct with that). I'm wondering if the default can be changed to be the fastest sane mode supported by the hardware and/or configured by the BIOS. In fact it's wrong when the user has selected a different mode from the BIOS setup especially on chips where we do not know how to fully program the hardware when switching modes correctly. Indeed. I just wasnt aware of the specifics of how things are currently done, and wether or not it is being done both optimally and safely. Stability trumping performance of course. ;o) I think the default should be whatever mode the chipset is in when AGP is started. Agreed, that was my opinion as well. I just wasn't 100% sure how it is currently defaulting, and I figured I'd ask here prior to examining the source code. Having the BIOS default to say 2x, and having X default to 1x, or worse, having the BIOS default to 8x and X default to 1x or 2x is the situation that I'm curious to determine if we're avoiding, or if it is a chipset specific thing, etc. Basically, someone has asked for me to default AGPMode to 4 in our config file, which I thought was absolutely crazy. The claim is that AGP defaulted to 1x, but changing it to 4x sped things up dramatically. That is what lead me to believe that the default being used is not the BIOS setting. I'm going to explore the source code tonight, and see what if anything I might be able to poke around. Thanks for the feedback David. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 3Dfx Voodoo 3, Banshee, Voodoo 1/2, and Voodoo Rush technicalspecifications
Anyone who might be interested on enhancing the XFree86 tdfx video driver, for 2D or 3D, or other functionality, will likely require the technical specs for the cards. The specs for all of these cards can be found in PDF format at the URL below. http://www.medex.hu/~danthe/tdfx/ Hopefully this information will be useful for some would be X hackers out there who have the hardware and would like to enhance support and/or fix bugs. I thought by providing links to the docs, it might help one get further along. Hope someone finds them useful. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] pagesize fixes for arch's where pages are not 4k
The DRI code makes invalid assumptions about page size being 4k. Most (all?) non x86 architectures use page sizes larger than 4k (alpha, ia64, etc..). I don't know how portable the patch is, but it has worked fine in Red Hat Linux for quite some time now. An alternative to using getpagesize() would be to have compile time conditional code, however that is a problem on some architectures, since some architectures have pagesize that is variable depending on the kernel you're using, etc. So I'm not sure if this is the best/most flexible solution or not, but it has at least worked now for us for quite a while, needing only slight changes with new XFree86 releases to patch cleanly. Please apply. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris --- xc/programs/Xserver/hw/xfree86/drivers/glint/glint_dri.c.fooSun Aug 5 16:23:24 2001 +++ xc/programs/Xserver/hw/xfree86/drivers/glint/glint_dri.cSun Aug 5 16:23:41 +2001 -405,7 +405,7 * for SAREA mapping that includes a device private record */ pDRIInfo-SAREASize = - ((sizeof(XF86DRISAREARec) + 0xfff) 0x1000); /* round to page */ + ((sizeof(XF86DRISAREARec) + getpagesize() -1) getpagesize()); /* round to +page */ /* + shared memory device private rec */ #else /* For now the mapping works by using a fixed size defined --- xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dri.c.fooSun Aug 5 16:22:27 2001 +++ xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dri.cSun Aug 5 16:17:10 +2001 -237,7 +237,7 * for SAREA mapping that includes a device private record */ pDRIInfo-SAREASize = -((sizeof(XF86DRISAREARec) + 0xfff) 0x1000); /* round to page */ +((sizeof(XF86DRISAREARec) + getpagesize() - 1) getpagesize()); /* round to page +*/ /* + shared memory device private rec */ #else /* For now the mapping works by using a fixed size defined --- xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_dri.c.foo Sun Aug 5 16:21:32 2001 +++ xc/programs/Xserver/hw/xfree86/drivers/tdfx/tdfx_dri.c Sun Aug 5 16:23:13 +2001 -357,7 +357,7 * for SAREA mapping that includes a device private record */ pDRIInfo-SAREASize = -((sizeof(XF86DRISAREARec) + 0xfff) 0x1000); /* round to page */ +((sizeof(XF86DRISAREARec) + getpagesize() - 1) getpagesize()); /* round to page +*/ /* + shared memory device private rec */ #else /* For now the mapping works by using a fixed size defined
[Dri-devel] Re: mach64 (Rage XL) trouble
On Wed, 1 May 2002, Kees Cook wrote: I've finally had a chance to upgrade to XFree86 4.2.0, and am trying out the bleeding edge builds for mach64. :) Quick version: it doesn't work. Long version: I think I have an AGP problem. glxinfo reports that direct rendering is off. the mach64 kernel driver compiled and is loaded, but agpgart errors out: mtrr: Serverworks LE detected. Write-combining disabled. ^^ Ick. Problem #1 mtrr: your processor doesn't support write-combining Problem #2 I'm at a loss! (And unfortunately, the ati driver is REALLY slow for just regular 2D stuff. I can watch things repaint, etc. Wasn't like that in XFree86 4.1.0...) Yep, you're not likely to see it get any better either unfortunately. Serverworks chipsets have an off by one problem in hardware with MTRR being used (if I've got the story I was told by Alan Cox correct), and as such MTRR is not available as it is purposefully disabled to prevent data corruption. That significantly slows down graphics. Also... AGP on Serverworks _sucks_. I strongly recommend against using Serverworks chipsets for any machines used for graphics. Server being the operative word for the chipset. ;o) If they were called Graphicsworks perhaps it would work better. ;o) What should I do next? Replace the motherboard with a chipset that has a working AGP implementation which both works, and is fast, and also has working MTRR support. Using Radeon with DRI on my Serverworks boards, with dual 1Ghz P-III Xeon CPU's, and 1Gb of RAM, I can watch the screen paint from top to bottom when switching windows - it takes about 1 second to paint the screen. This is in my case due to the Radeon CP engine 2D acceleration not accelerating everything it does in MMIO mode. That latter part wont affect you on Mach64 though likely. Bad news.. ;o( -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM causes video lock on virtual console switching
On Sat, 13 Apr 2002, K. Petersen wrote: Date: Sat, 13 Apr 2002 16:16:19 -0700 (PDT) From: K. Petersen [EMAIL PROTECTED] To: Jens Owen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: MULTIPART/MIXED; BOUNDARY=-1936846907-1397867424-1018735485=:101992 List-Id: dri-devel.lists.sourceforge.net Subject: Re: DRM causes video lock on virtual console switching On Sat, 13 Apr 2002, Jens Owen wrote: Okay, let's turn off the BuiltInRadeon option for now, that's just for the 3D driver anyway. Building a static server would give us a much more useful stack... Here we are, two new stacks from the hung X. The first is of a modular X, created with the patched gdb from Mike A Harris. The second is from a static X built with the last host.def that you posted. Both of these still have a ?? function call. I didn't follow what to do with the suggestion of call LoaderPrintSymbol for the address of each '??', as Mike Harris suggested, so I don't have a proper identity for this functions. I'd be willing to identify this function if I recieved some guidance on how to do so. Hope these files provide you with something useful to work with in the meantime. You have to load the symbols from the module files before you will get meaningful names. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM causes video lock on virtual console switching
On Wed, 10 Apr 2002, K. Petersen wrote: I have come upon a reproducible lockup on my system when switching from a console virtual terminal to X. It can be produced as follows: Begin X Switch back to a virtual console Switch back to X This causes the X display to appear on the screen, with a strip along the top deformed. In this state, the X server is unresponsive to ctrl-alt-backspace, and I am unable to switch to any other virtual terminals. However, I can still log in remotely. Using alt-sysreq-k, the display then changes colors, to what I believe might be a lower color palatte, but cannot be certain of. After this, I am then able to switch virtual terminals, log in as root, run mode3, and have the display restored. At this point, vc/7 has not been restored to an unused state. Instead there is any text I typed while the display was locked, followed by a blinking cursor. If I now attempt to restart X, the system will lock completely. The monitor will go into power saving mode, the keyboard is unresponsive, and I am unable to log in remotely. I hope this has been a reasonably thorough description of the problem, now my hardware and software configuration. Hardware: ATI Radeon 64DDR AMD AthlonMP in SMP configuration AMD 760MP chipset on a Tyan S2460 Motherboard Software: Linux kernel 2.4.18 Latest DRI cvs, with kernel module from the dri This problem has occurred since X410, and kernel versions back at least through 2.4.16, both with kernel DRM, and the DRM provided with the DRI. I should also note that this only occurs when DRI is enabled. There is no problem switching between X and other virtual terminals when DRI is disabled. I believe this to be the correct forum for this issue, but if it is not, then feel free to forward me to the linux kernel lists or whatever's more appropriate. I thank you in advance for your assistance, We have massive reports of VT switching hangs in XFree86 4.2.0 with almost all Radeon hardware, but with other hardware as well. This problem has occured aparently since the prereleases 4.1.99.* and up through to the final release of 4.2.0. The kernel version doesn't seem to make any difference. As I understand, the Radeon is not being initialized properly or restored properly, however it occurs on other hardware as well. The problem seems common enough that I'm surprised it has not been determined yet, althought it seems that it is not one problem, but is more likely individual problems in different drivers, and the kernel isn't ruled out either. I've tried debugging it myself but have yet to determine the problem or a solution. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM causes video lock on virtual console switching
On 13 Apr 2002, Michel Dänzer wrote: Date: 13 Apr 2002 16:36:27 +0200 From: Michel Dänzer [EMAIL PROTECTED] To: K. Petersen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 List-Id: dri-devel.lists.sourceforge.net Subject: Re: DRM causes video lock on virtual console switching On Sat, 2002-04-13 at 03:58, K. Petersen wrote: #1 0xfc02 in ?? () #2 0x0832575e in ?? () #3 0x086da341 in ?? () #4 0x0876ced1 in ?? () #5 0x0816be18 in miSpritePaintWindowBackground (pWin=0x878c118, pRegion=0x875cd10, what=0) at misprite.c:844 #6 0x0815f580 in miWindowExposures (pWin=0x878c118, prgn=0x875cd10, other_exposed=0x0) at miexpose.c:536 #7 0x080a6a8a in xf86XVWindowExposures (pWin=0x878c118, reg1=0x875cd10, reg2=0x0) at xf86xv.c:1027 #8 0x0832134a in ?? () Either call LoaderPrintSymbol for the address of each '??', use a gdb with support for XFree86 modules or a static server. I've got gdb compiled with X module debugging support available on ftp://people.redhat.com/mharris/gdb-xfree86 It allows one to debug a normal modular X server. Red Hat Linux users can rebuild the XFree86 src.rpm with full debugging enabled by doing: rpm -ivh XFree86-4.2.0-*.src.rpm cd /usr/src/redhat/SPECS edit the XFree86.spec file, look for the line Release: and add dbg to the end of the release number. Then look for DebuggableBuild option, and change it from 0 to 1, then save and exit. Then rebuild new XFree86 rpms with debug support by doing: rpm -bb XFree86.spec It requires about a gigabyte of free disk space, and likely several hours depending on how fast your system is. The resulting XFree86 rpm packages are HUGE. ;o) Hope this helps anyone who might be debugging in an rpm environement. The patched gdb should be rebuildable under any other OS/distribution as well. Hope this helps. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Red Hat glide problem (was What about a trunk update to 4.0.2?)
On Sat, 6 Apr 2002, Brian Paul wrote: Date: Sat, 06 Apr 2002 08:56:32 -0700 From: Brian Paul [EMAIL PROTECTED] To: DRI-Devel [EMAIL PROTECTED], [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Red Hat glide problem (was What about a trunk update to 4.0.2?) Brian Paul wrote: Unfortunately, I'm seeing a far worse problem with the tdfx driver now with most demos. Triangles are being rendered incorrectly - it's as if one of the vertices for each triangle is at screen coordinate (0,0). I'm looking into it. The problem was the glide library. I had recently wiped my test machine clean and installed RH 7.2 which installs glide libraries as part of the XFree86-libs-4.1.0-3.i386 RPM. After I replaced /usr/lib/glide3/libglide3-v5.so with the one from the DRI resources page, the problem went away. Mike, is this a known problem? There has been a problem reported to us, which appears to be fixed by using the Glide3 lib on the SF page according to reports like the above. I'm not sure if the sources used in both cases are the same, or if it is just a flaw in our build process for the Voodoo5 Glide3 library. I suspect the way we are building it has been flawed slightly, which is the likely cause of the problem. I've planned on looking into the problem, and making test builds, however I cant test it myself as I dont have the hardware. Is anyone on this list, who has a Voodoo 4 or 5, interested in working with me and beta testing some new Glide3 builds with our current XFree86 4.2.0 packages? If so, we can likely ensure this is fixed in the next release. Thanks Brian for the reminder about this. Take care, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: G400 Compatibility Test Results
On Mon, 8 Apr 2002, Ian Romanick wrote: Date: Mon, 8 Apr 2002 16:00:05 -0700 From: Ian Romanick [EMAIL PROTECTED] To: DRI developer's list [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary=J/dobhs11T7y2rNN List-Id: dri-devel.lists.sourceforge.net Subject: G400 Compatibility Test Results I'm sending this as an HTML attachment. If this causes anybody problems, let me know and I can re-send as plain text. Doesn't cause any problems.. just can't read it. ;o) -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel Sponsored by http://www.ThinkGeek.com/
[Dri-devel] Weekly #dri-devel meeting in progress on irc.openprojects.net
Weekly reminder notice about the meeting. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: Downloadable Radeon Driver and libGL compatability
On Fri, 8 Mar 2002, Jens Owen wrote: I've moved this field to the end of the structure and the libGL.so compatability issue appears to be fixed. Hmmm, that might be good enough, but I'm not 100% certain. I'm worried that my hack of moving it to the end could possibly end up writing over the end of the structure allocation. So, I'd like to try your suggested fix of using the currentDrawable fied. Wasn't this stuff recently submitted to the DRI trunk? Maybe we can fix this incompatability if this hasn't propogated out to any major distros, yet. Yes, we should really fix it ASAP. Was this part of Mesa 4? So this wouldn't have gone out in XFree86 4.2 or any other source releases where we care about binary compatability, right? The latest official releases of X we've shipped are 4.1.0 with Mesa 3.4.2, so whatever you change is not likely to affect us. I've looked through several other mainstream distros, and I do not believe anyone has shipped anything yet in an official capacity using Mesa 4.0, XFree86 4.2.0. You may want to contact other distro maintainers perhaps however. It would be nice if this can be fixed the proper way as you recommend, if possible. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Friendly neighborhood #dri-devel meeting reminder.
Just a reminder of the weekly #dri-devel meeting on irc.openprojects.net at 4pm EST today. That's 2100 UTC, and 1pm PST. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: radeon7500 + irongate agp chipset: are the problems being workedon?
On Sun, 17 Feb 2002, Andrew Schwerin wrote: I'm running with a Radeon VE and having a similar problem. All apps that use DRI eventually (within 10 minutes, often less than 1 minute) lock up the system. I've got an A7A266. Contrary to the experience of the users, I've had more trouble when I turn the AGP speed down from 4x to 1x, though reducing the aperature size has helped a little. I've now tested Radeon, Radeon 7500 a fair bit with 4.2.0, and am also experiencing this exact same thing. Upon starting up gears, it runs normal for about 2 seconds, then slows down to slower than software rendering instantly for about 3-5 seconds, then speeds up a bit, then goes back to full speed, and stays there. Eventually it crashes X, and sometimes the whole system. Running Chromium also crashes the system at the main screen. Running random GL screensavers crash also. In some cases, after the initial crash, the system is still running. I ssh in, and can kill X, etc.. all processes are in S state at that time. No log files show anything suspicious. Killing X and restarting it always leads to full system lockup requiring a hard reset. I cant get any OpenGL applications to run for long without locking up the X server and/or kernel. I'm using our rawhide 2.4.17-0.16 kernel rebuilt for i586 UP on a K6-3 300Mhz CPU. I haven't yet tried to debug things further, but am willing to test any kernel/X patches out. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Matrox G550?
On Wed, 20 Feb 2002, Keith Whitwell wrote: Since the G550 is, basically, just a slightly enhanced G400/G450, it is supported by the DRI, right? If so, then does anyone have any information about the partial TL support in the G550? Now that we've got some TL support for the Radeon, it might be nice to look at this card, too. I don't have any information about it, in fact I've never had access to one of the cards to test or verify that the driver works on it. However, if you can get doco, it should be reasonably easy to add transformation support (I don't think the card does lighting???). I suppose it's probably the classic problem, though: those that have the required docs won't share. I don't know of anyone who does have docs. You may have good luck contacting Matrox directly. To the best of my knowledge, Matrox no longer releases documentation of their hardware to open source projects and developers. The last documentation that is available I believe is the G400. From what I understand, the documentation contains information on defeating Macrovision. I wonder why they couldn't just remove sensitive information though or redact it out. At least Matrox supports their hardware via in house development patches though. Possibly someone at Matrox would consider writing support for missing features, if not in official capacity, perhaps on their spare time. Not sure if anyone from Matrox reads the list or not, but it might be a good idea to contact Luugi Marsan or Karl Lessard perhaps. Just a thought. TTYL -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are theproblems being worked on?
On 21 Feb 2002, Andrew Schwerin wrote: Date: 21 Feb 2002 02:55:38 -0800 From: Andrew Schwerin [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain Subject: Re: [Dri-devel] Re: radeon7500 + irongate agp chipset: are the problems being worked on? Hehe. I feel mildly sheepish. My system wasn't locking hard. Only the keyboard, mouse and video card were locking. I was able to connect over the network to my machine in order to shut it down safely last time it locked up. It still hoses the Radeon VE card and the keyboard, but that's better than I thought. Yep, I thought it was dead at first too, until I could ssh in. It is completely repeatable though. I tried on 3 different machines now, each with a Radeon 7500, a Radeon 64DDR and a Radeon VE. In all cases using 4.2.0 plus kernel 2.4.17+new DRM. Unstable for me. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
