Re: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
David Dawes wrote: No, I think it should be intel_845_setup too, since the 845G docs on Intel's public web site show that the behaviour is like the 845 when the on-board graphics isn't enabled. I made that change in my locally maintained version of the agpgart driver a little while ago, but haven't had the opportunity to test it with an external AGP card in an 845G box yet. Damn, you're right. Now I got the docs from Intel (at the time were the patch to support 845g was submitted, they were just not available yet), and truly the specs are closer to the 845, so let's switch to 'intel_845_setup' to initialize the 845g. Not that it should change things too much, but it will avoid further confusions Best regards. Nicolas PS: I hope the IBM annoyances for mails sent to lkml stopped... -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) --- 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 Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). That would mean the DRM of the day gets more exposure to external review and we find bugs in the kernel side (be they X or kernel caused) rapidly, as well as submitting back changes to the common repository so that when a new major Linux kernel appears DRM just works. Alan --- 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, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Alan. --- 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
Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. My feeling is that the dri cvs should be that place. What workable alternatives exist? It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). This is the biggest unknown, I think - there are multiple sources that have a reasonable claim to this throne -- whatever was in the last XFree86 release -- XFree86 stable cvs (which differs only slightly from above) -- the newly created dri stable branch -- etc. We've had some discussions about stable branches for other purposes (binary compatibility concerns with XFree versions), however it would make reasonable sense for this to be the definitive 'stable' source for drm modules also. That would mean the DRM of the day gets more exposure to external review and we find bugs in the kernel side (be they X or kernel caused) rapidly, as well as submitting back changes to the common repository so that when a new major Linux kernel appears DRM just works. We've been very lucky in that Linus has been pulling changes into 2.5 and providing some useful feedback when things go wrong. I don't know how sustainable this is though - I think we're probably taking up more of his time than we should be. How would you ideally see this working? Keith --- 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, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Or 4.2.x for most recent x? What about bugs that are found in the modules after XFree is released? Or api changes within the kernel? Sorry - yes 4.2.1 or most recent 4.2.x. As for bugs found or api changes they should be submitted back to XFree86 so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x release - if there was to be one. Alan. --- 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
Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Or 4.2.x for most recent x? What about bugs that are found in the modules after XFree is released? Or api changes within the kernel? Keith --- 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
Am Donnerstag, 12. Dezember 2002 13:58 schrieb Alan Hourihane: On Thu, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Or 4.2.x for most recent x? What about bugs that are found in the modules after XFree is released? Or api changes within the kernel? Sorry - yes 4.2.1 or most recent 4.2.x. As for bugs found or api changes they should be submitted back to XFree86 so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x release - if there was to be one. Sorry, but I think this is much to slow/few. Look at the current kernel (drm) source. There are daily changes/fixes and we should use the latest XFree (DRI) DRM? Currently I'm under the impression that nobody (only a few) of the XFree/DRI developers pay attention about SMP and/or latency where some Linux kernel affords go. Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell for some apps on my SMP system. Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Only some thoughts. -Dieter --- 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
Sorry, but I think this is much to slow/few. Look at the current kernel (drm) source. There are daily changes/fixes and we should use the latest XFree (DRI) DRM? Currently I'm under the impression that nobody (only a few) of the XFree/DRI developers pay attention about SMP and/or latency where some Linux kernel affords go. Well, that's the problem that we're addressing -- the changes from different people are going to different places, so there's no single good source. Keith --- 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, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote: Am Donnerstag, 12. Dezember 2002 13:58 schrieb Alan Hourihane: On Thu, Dec 12, 2002 at 12:53:46PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Or 4.2.x for most recent x? What about bugs that are found in the modules after XFree is released? Or api changes within the kernel? Sorry - yes 4.2.1 or most recent 4.2.x. As for bugs found or api changes they should be submitted back to XFree86 so they can be applied to the stable xf-4_2-branch ready for a new 4.2.x release - if there was to be one. Sorry, but I think this is much to slow/few. The speed of updates wasn't the original question, it was where to get the right stable or development DRM modules. Look at the current kernel (drm) source. There are daily changes/fixes and we should use the latest XFree (DRI) DRM? Currently I'm under the impression that nobody (only a few) of the XFree/DRI developers pay attention about SMP and/or latency where some Linux kernel affords go. If people decided to upgrade their kernel, they'd already get a later DRM that should function with the latest XFree86 4.2.x release regardless of whether the DRI trunk DRM modules have anything to do with it. Thus getting whatever bug fixes are in the later kernel. Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell for some apps on my SMP system. Forget the DRI trunk for a second, what does 2.4.20 do with XFree86 4.2.x ? That should be stable. As for your question, have you posted more details on the problem ? Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Linus should submit it here for inclusion - simple. I doubt any of us are tracking 2.5.x that closely at the moment. Alan. --- 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 Don, 2002-12-12 at 14:50, Dieter Nützel wrote: Look at the current kernel (drm) source. There are daily changes/fixes and we should use the latest XFree (DRI) DRM? Currently I'm under the impression that nobody (only a few) of the XFree/DRI developers pay attention about SMP and/or latency where some Linux kernel affords go. Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell for some apps on my SMP system. Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. As Keith pointed out, we can't track all the DRM changes outside of our tree. We need the people making those changes submitting them to us, which happens rarely, if ever. I'd appreciate a lot if it did. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote: It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. There should at the least be one person on the DRI team who looks at each new kernel releases with a Are there any changes here I need to push into DRI CVS mindset. This job doesn't need you to even monitor l-k, just keep an eye on each release Linus does. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- 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, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote: Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Linus should submit it here for inclusion - simple. I doubt any of us are tracking 2.5.x that closely at the moment. I'm surprised Linus finds the time to do the DRI merges he does already. Pushing stuff back to DRI-devel is going to take up even more of his time, so this should ideally be done by someone else, preferably someone who really understands the code. Dave -- | Dave Jones.http://www.codemonkey.org.uk | SuSE Labs --- 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
Dave Jones wrote: On Thu, Dec 12, 2002 at 02:09:18PM +, Alan Hourihane wrote: Some apps only run smooth with 2.5.49+ kernels due to Linus latest work. Nothing of it in XFree or DRI, yet. Linus should submit it here for inclusion - simple. I doubt any of us are tracking 2.5.x that closely at the moment. I'm surprised Linus finds the time to do the DRI merges he does already. Pushing stuff back to DRI-devel is going to take up even more of his time, so this should ideally be done by someone else, preferably someone who really understands the code. Yes. What Linus does is above and beyond what we could/should reasonably expect. Asking him to do more isn't an option. Keith --- 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
Am Donnerstag, 12. Dezember 2002 15:09 schrieb Alan Hourihane: On Thu, Dec 12, 2002 at 02:50:39PM +0100, Dieter Nützel wrote: Latest trunk with 2.4.20 kernel DRM or the DRI DRM module stutters like hell for some apps on my SMP system. Forget the DRI trunk for a second, what does 2.4.20 do with XFree86 4.2.x ? That should be stable. As for your question, have you posted more details on the problem ? See [Dri-devel] radeon.o DRM modules breaks my CD player (!) thread. -Dieter --- 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] Mesa/DRI version for XFree86 4.3
On Don, 2002-12-12 at 15:29, Martin Spott wrote: XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time constraints and stability concerns. [...] I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you chose for XFree86-4.3, I'd mostly agree, but I guess the floating point exceptions are showstoppers. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] Version handshake problems?
On Die, 2002-12-10 at 19:08, Carlos O'Donell wrote: /proc/dri shows 0, 1 and 2. 0 - tdfx 0xe200 (The Matrox) 1 - radeon 0xe201 PCI:1:0:0 (Radeon 7500 QW AGP) 2 - radeon 0xe202 (Radeon, the VGA interface?) No, the radeon DRM actually only registers a single instance. This had me very stumped, but someone else reported it before, and it turned out to be the DRM already built into the kernel. Do I get the prize now? :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] 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
[Dri-devel] bugreport: http://people.debian.org/~daenzer/dri-mach64/
hi, I'm send this email to both adresses, because i don't know, if problem is in package or DRI .. I have Debian Unstable and ATI (rage pro) Mobility graphics card. I downloaded xserver-xfree86-dri-mach64 and drm-mach64-module-src from page in subject, made .deb by make-kpkg and installed it. Problem is, that KDM don't want to run anymore. I see, that X server started, but then it restarted. (see attached files) I have KDM 3.1 rc4, but I had the same problem on KDM 3.0. and XFree86Server 4.2.1. Funny is, that when I put startx, it works well (except that I change to console before kde is fully loaded) so please help if you can.. -- Vladimir Wiedermann log.tgz Description: GNU Unix tar archive
Re: [Dri-devel] Mesa/DRI version for XFree86 4.3
Brian Paul wrote: Michel Dänzer wrote: On Don, 2002-12-12 at 15:29, Martin Spott wrote: XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time constraints and stability concerns. [...] I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you chose for XFree86-4.3, I'd mostly agree, but I guess the floating point exceptions are showstoppers. It's still not clear what the cause of this is. I've heard two possibilities: 1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with a command line switch. 2. A bogus test in Mesa determines that newer P4 processors have 3Dnow support. This was fixed in the Mesa/src/X86/common_x86_asm.S file last month. Neither of these seems to explain what's happening. Keith --- 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] Mesa/DRI version for XFree86 4.3
On Thu, Dec 12, 2002 at 11:43:03AM -0700, Brian Paul wrote: Michel Dänzer wrote: On Don, 2002-12-12 at 15:29, Martin Spott wrote: XFree86 4.3 is going to go with a Mesa 4.0.x-based DRI because of time constraints and stability concerns. [...] I didn't notice the Mesa-5.x-based stuff is less stable than the stuff you chose for XFree86-4.3, I'd mostly agree, but I guess the floating point exceptions are showstoppers. It's still not clear what the cause of this is. I've heard two possibilities: 1. The new gcc (3.2 ?) emits MMX or SSE code unless you inhibit it with a command line switch. 2. A bogus test in Mesa determines that newer P4 processors have 3Dnow support. This was fixed in the Mesa/src/X86/common_x86_asm.S file last month. Neither of these explain the sigfpe that Andreas Stenglein and I have been experiencing. Both of us have been building with gcc 2.95: this eliminates 1. In addition, I have confirmed that I've been running the fixed code: this eliminates 2. See (a.o.) the mail with subject: Re: [Dri-devel] Re: Radeon: lockup on state change Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- 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] Re: Floating point exception
On Wed, Dec 11, 2002 at 09:34:23AM -0800, dax wood wrote: the CPU i got is vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 3 cpu MHz : 701.601 cache size : 256 KB The ENV var 'MESA_NO_SSE' has no effect at all. I Recompiled the cvs this time with #define MesaUseKatmai YES To make any difference, you'd have to change it to NO. commented out and yet still recieve Floating point exception a notable mention thought when dri is disabled I am able to run all opengl programs (slowly). the odd thing is that I cant find the error msg Floating point exception in any of the sources. Is this in kernel? What version of GCC are you using? If you're using 3.2.x, try adding '-mno-sse -mno-mmx -mno-3dnow' to DefaultGcc2i386Opt in host.def and make World. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- 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
Dave Jones wrote: On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote: It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. There should at the least be one person on the DRI team who looks at each new kernel releases with a Are there any changes here I need to push into DRI CVS mindset. This job doesn't need you to even monitor l-k, just keep an eye on each release Linus does. I'm running through the differences between dri trunk and 2.5.51 now, with the aim of pulling stuff back. So far nothing huge has jumped out at me. Keith --- 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
Dave Jones wrote: On Thu, Dec 12, 2002 at 12:49:37PM +, Keith Whitwell wrote: It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. There should at the least be one person on the DRI team who looks at each new kernel releases with a Are there any changes here I need to push into DRI CVS mindset. This job doesn't need you to even monitor l-k, just keep an eye on each release Linus does. Dave, I expect the changes Linus makes will run with the kernels he releases, but my question is, will they work with older kernels, too? The DRI cvs sources need to support those as well? Supporting DRM under stable and development XFree86 as well as stable and development Linux Kernel seems like a large job when your consider compatability with older releases (of XFree86 and kernel), the number of drivers, and the code being shared with other operating systems. My point is this may require more of an effort than simply merging Linus' changes back into the DRI tree. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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] Segfault in DRI Xserver extension
Felix Kühling wrote: Hi, while I was messing around with my query programme I found this: if I specify an invalid screen as argument to XF86DRIGetClientDriverName the Xserver segfaults. I had a quick look at xc/xc/Xserver/GL/dri/xf86dri.c. stuff-screen is used as array index without checking. I'm not sure though, where would be the right place to fix it. Other functions in xf86dri.c must be affacted, too. They use stuff-screen in the same way. Those functions should validate any information they receive over the wire, as soon as is feasible. Keith --- 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
[Dri-devel] vblank and i810
Well I asked a question on dri-users and Keith said I'd be better asking here .. I want to get my OpenGL application to stop flickering on my i815 using a sync to the vertical refresh, work has apparently started on this for the radeon and g400, so, a) does someone intend working on the i810 driver? b) if !a, where do I start to work on this, I have a development system sitting here waiting :-), and I've no fear of X or kernels, Do I need a particular branch of the dri CVS tree or will the HEAD do fine? Do I need an updated X11/GL to support the new IOCTL? (am running XFree86 4.2.0) Can I avoid downloading/building the Xserver, just grab the DRI stuff? Will this be in 4.3 (I have to do a product and a stable release looks better to management!). Thanks, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- 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] bugreport: http://people.debian.org/~daenzer/dri-mach64/
This probably won't help with kdm, but did you also install the xlibmesa* packages? I think those contain the mach64 Mesa driver (mach64_dri.so) among other things, that you'll need to use DRI. On Thu, 12 Dec 2002, Vladimir Wiedermann wrote: hi, I'm send this email to both adresses, because i don't know, if problem is in package or DRI .. I have Debian Unstable and ATI (rage pro) Mobility graphics card. I downloaded xserver-xfree86-dri-mach64 and drm-mach64-module-src from page in subject, made .deb by make-kpkg and installed it. Problem is, that KDM don't want to run anymore. I see, that X server started, but then it restarted. (see attached files) I have KDM 3.1 rc4, but I had the same problem on KDM 3.0. and XFree86Server 4.2.1. Funny is, that when I put startx, it works well (except that I change to console before kde is fully loaded) so please help if you can.. -- Leif Delgass http://www.retinalburn.net --- 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: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. I would love to see this as well. I am not sure that this two tree CVS devel method is the most efficient. I am sure it was started for good reasons, but I think it taxes some time for people like me who try keep testing the big picture by running both trees in one. 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). I like that idea ... essentially two copies of DRM in the kernel tree. One that is visible always as it is considered most stable with the current release of XFree86 and the running experimental version. Admittably the compatibility with modules also depends on what version of XFree86 as you noted above - it sure ... complicates things. I guess at some point we have to believe that if you are building your own kernel that you are reasonably competent to figure that one out. Not always the case, but unfortunately it is so hard to check the intelligence sitting in front of the console with a configuring script. ;-) 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. I admit that your logic is sound, but answer me this: Does one send the changes back on the stable to the XFree86 team proper or to the DRI team? The two group devel model gets kinda unwieldy at this point. Right now most vendors have to track the individual patches to XFree86 and DRI in between releases ... and they kinda push the changes back into the code base where they belong when they can. Surely we can thing of a better way to do the tango to help everyone out ... -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- 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
[Dri-devel] Re: bugreport: http://people.debian.org/~daenzer/dri-mach64/
On Don, 2002-12-12 at 19:23, Vladimir Wiedermann wrote: I'm send this email to both adresses, because i don't know, if problem is in package or DRI .. I have Debian Unstable and ATI (rage pro) Mobility graphics card. I downloaded xserver-xfree86-dri-mach64 and drm-mach64-module-src from page in subject, made .deb by make-kpkg and installed it. Problem is, that KDM don't want to run anymore. I see, that X server started, but then it restarted. (see attached files) I have KDM 3.1 rc4, but I had the same problem on KDM 3.0. and XFree86Server 4.2.1. Funny is, that when I put startx, it works well (except that I change to console before kde is fully loaded) See /usr/share/doc/xserver-xfree86-dri-mach64/README.Debian . -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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] Re: Floating point exception
On Don, 2002-12-12 at 21:55, dax wood wrote: (WW) R128(0): Can't determine panel dimensions, and none specified. Disabling programming of FP registers. ::: honestly i think this bug is in the r128 implementation of Mesa 5.0 That message is from the r128 2D driver and has nothing to do with Mesa. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: ... It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. May I suggest that the best way to do that, is to keep the kernel DRM code, as a **SEPARATE PROJECT**, at least on the source code repository level. IMO, there should be a separate repository, or at least a separate directory at the same level as the top-level xc. The only thing from the driver that really belongs buried in the xfree86 server code, is a single, os-neutral copy of drm.h, from whatever version of DRM that branch of xfree86 is officially supporting. Once you have achieved that separation, you have something actually resembling a formal API between user-level and kernel driver level. That is the only way things are going to get cleaned up, process-wise. Not to mention greatly aiding kernel coding efforts for non-linux platforms. --- 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
[Dri-devel] problems with CVS head and i810
Well I built the CVS tree head and made the i810 modules and ran my test opengl program on it and it worked the first time then started spewing errors ala (II) I810(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x pgetbl_ctl: 0x7e40001 pgetbl_err: 0x0 ipeir: 0 iphdr: c2fb LP ring tail: a0 head: 94 len: f001 start 2ac000 eir: 0 esr: 1 emr: 3d instdone: ff7a instpm: 0 memmode: 4 instps: 10 hwstam: 9ac7 ier: 0 imr: 9ac7 iir: 0 Fatal server error: Active ring not flushed dmesg has this to say: [drm] Initialized i810 1.2.1 20020211 on minor 0 mtrr: base(0xf800) is not aligned on a size(0x12c000) boundary PCI: Found IRQ 11 for device 00:02.0 [drm:i810_wait_ring] *ERROR* space: 65508 wanted 65528 [drm:i810_wait_ring] *ERROR* lockup I had set the library path to pick up the newer version of the GL libs.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- 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, Dec 12, 2002 at 11:11:13AM -0600, D. Hageman wrote: On Thu, 12 Dec 2002, Alan Hourihane wrote: 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. I admit that your logic is sound, but answer me this: Does one send the changes back on the stable to the XFree86 team proper or to the DRI team? The two group devel model gets kinda unwieldy at this point. Right now most vendors have to track the individual patches to XFree86 and DRI in between releases ... and they kinda push the changes back into the code base where they belong when they can. I'd send stability changes directly to XFree86. Then the changes would go straight into the stable branch of XFree86. There's a close working relationship between the two groups anyway and if the XFree86 team want a quick response from the DRI folks on a patch they've received then that would happen. Alan. --- 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, 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 ? --- 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, 2002-12-12 at 12:49, Keith Whitwell wrote: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. My feeling is that the dri cvs should be that place. What workable alternatives exist? That seems right. It seems that changes get inserted to the drm code in the kernel from time to time. Is the expectation that we monitor the kernel drm and periodically merge (or otherwise) those random or worthy changes back to this repository? I personally don't want to subscribe to lkml or attempt to fully monitory the traffic there. Thats why I said its not just about what we need. Ok so DRI CVS is definitive and has branches for 4.2.0/4.2.1/devel. So if I make sure all the Linux changes to 2.4.x DRM get channeled back to this list they can get reviewed and merged back and we are all happy. Thats trivial for me to do since I'm already seeing each patch that touches that area. We've been very lucky in that Linus has been pulling changes into 2.5 and providing some useful feedback when things go wrong. I don't know how sustainable this is though - I think we're probably taking up more of his time than we should be. How would you ideally see this working? Mostly I want to know how to make sure changes stick once they are made and deemed or shown to work. If the Linux fixes get back into the DRM CVS, then the only other bit is knowing when the DRM CVS has changed. That sounds like a procmail filter on the commit notify list for DRI if there is one set up. Right now for 2.4 I'm juggling too many conflicting balls, if its all in the DRM CVS then merging stuff added to DRM cvs is a real nobrainer, and since I can do it item by item as it changes its also easy to know when something bad happens. Alan --- 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] DRM Kernel Questions
On Thu, 12 Dec 2002, Mike A. Harris wrote: On Thu, 12 Dec 2002, Alan Hourihane wrote: The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them for things pci_alloc_consistent ? No, nor does 4.2.1. Should anyone be using XFree86 CVS stable branch DRM nor trunk DRM then? I presume if bugfixes are not going into XFree86 CVS stable branches, that the DRM in there is snapshoted and then throwaway. This is pretty much what my claim was the other day when we were talking on IRC ... one needs to see the DRI stuff moved into the XFree86 CVS tree on a regular basis to see any decent results. This is why I take the time to merge in the DRI stuff everytime I build new RPMs to test XFree86 code. Changes to the XFree86 code proper seems to not be getting moved over as quickly as it should. If we want to take a recent example - we can use the xf86strncat symbol missing out of the loader code. The issue was first noticed in the DRI tree, but the change didn't get put into the XFree86 tree until about two weeks later ... and then it was just because I happened to make an off hand comment about it on the xfree86-devel list. I checked the vendor and what not tags on the RPMs I built for myself and you are correct that they are undefined. I really like that new version of RPM. It does nice things [tm]. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- 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, Dec 12, 2002 at 07:14:45PM -0800, Philip Brown wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: ... It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. May I suggest that the best way to do that, is to keep the kernel DRM code, as a **SEPARATE PROJECT**, at least on the source code repository level. IMO, there should be a separate repository, or at least a separate directory at the same level as the top-level xc. The only thing from the driver that really belongs buried in the xfree86 server code, is a single, os-neutral copy of drm.h, from whatever version of DRM that branch of xfree86 is officially supporting. Once you have achieved that separation, you have something actually resembling a formal API between user-level and kernel driver level. That is the only way things are going to get cleaned up, process-wise. Not to mention greatly aiding kernel coding efforts for non-linux platforms. And there are also people wanting to use the DRM outside of XFree86, maybe even outside of the DRI, not sure though. Friendly, Sven Luther --- 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
[Dri-devel] Radeon DRI resume - submission to XFree86 CVS
As discussed in the mail below, herewith a submission of the Radeon DRI suspend/resume patch for your review. I've updated it to and tested it with current XFree86 CVS. FYI, this patch enables complete suspend to/resume from disk with Radeon chipsets with active DRI (and also running 3D-accelerated and Xv clients). More information is available at http://cpbotha.net/dri_resume.html Thanks, Charl - Forwarded message from David Dawes [EMAIL PROTECTED] - From: David Dawes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Dri-devel] Radeon DRI Resume - quo vadis? X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.9-sf.net List-Help: mailto:[EMAIL PROTECTED]?subject=help List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/dri-devel, mailto:[EMAIL PROTECTED]?subject=subscribe List-Id: dri-devel.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/dri-devel, mailto:[EMAIL PROTECTED]?subject=unsubscribe List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=dri-devel X-Original-Date: Tue, 10 Dec 2002 21:09:27 -0500 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: X-Keywords: X-UID: 363 On Tue, Dec 10, 2002 at 01:45:09PM +0100, Charl P. Botha wrote: On Tue, 2002-12-10 at 13:36, Alan Hourihane wrote: One thing though. It doesn't look like it's hooked to any APM events. It's just run generically everytime on ModeInit. What happens when you VT switch - does it handle them cases too ? At the moment it's called from RADEONEnterVT() in radeon_driver.c - so the code is called after every VT switch. During normal operation this doesn't cause any problems as it's idempotent. I would prefer hooking it more specifically to a power event... however, last time I checked the infrastructure for non-APM power events didn't seem to be ready. Many people are using this on ACPI-only laptops with swsusp for software suspension. If you're restoring HW state required for the correct operation of the driver, and especially if it's state that something else driving the video card might change while the X server doesn't have control over it, then it should be done from EnterVT(). As a general rule, any HW state that's set in ScreenInit() should also be set in EnterVT(). By default, XFree86 handles APM events via EnterVT/LeaveVT. It's possible for a driver to provide a separate function to handle PM events, but in most cases it shouldn't be needed. I just had another look at your patch, and I didn't see any obvious problem with the way it's structured. Send it to [EMAIL PROTECTED], and Kevin Martin can review it. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes - End forwarded message - -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ Index: drivers/ati/radeon.h === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.h,v retrieving revision 1.32 diff -u -r1.32 radeon.h --- drivers/ati/radeon.h2002/10/31 18:06:59 1.32 +++ drivers/ati/radeon.h2002/12/12 18:45:10 @@ -566,12 +566,15 @@ extern int RADEONMinBits(int val); extern voidRADEONInitVideo(ScreenPtr pScreen); - +/* added by [EMAIL PROTECTED] so that we can call this function from + * radeon_driver.c to get xvideo working after a resume from disc/ram */ +extern voidRADEONResetVideo(ScrnInfoPtr pScrn); extern voidR300CGWorkaround(ScrnInfoPtr pScrn); #ifdef XF86DRI extern BoolRADEONDRIScreenInit(ScreenPtr pScreen); extern voidRADEONDRICloseScreen(ScreenPtr pScreen); +extern voidRADEONDRIResume(ScreenPtr pScreen); extern BoolRADEONDRIFinishScreenInit(ScreenPtr pScreen); extern drmBufPtr RADEONCPGetBuffer(ScrnInfoPtr pScrn); Index: drivers/ati/radeon_common.h === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h,v retrieving revision 1.1 diff -u -r1.1 radeon_common.h --- drivers/ati/radeon_common.h 2002/10/30 12:52:13 1.1 +++ drivers/ati/radeon_common.h 2002/12/12 18:45:10 @@ -70,6 +70,7 @@ #define DRM_RADEON_INIT_HEAP 0x15 #define DRM_RADEON_IRQ_EMIT 0x16 #define DRM_RADEON_IRQ_WAIT 0x17 +#define DRM_RADEON_CP_RESUME 0x18 #define DRM_RADEON_MAX_DRM_COMMAND_INDEX 0x39 Index: drivers/ati/radeon_dri.c === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v retrieving revision 1.22 diff -u -r1.22 radeon_dri.c --- drivers/ati/radeon_dri.c2002/11/25 14:04:57 1.22 +++ drivers/ati/radeon_dri.c2002/12/12 18:45:10 @@ -1559,6 +1559,86 @@ return TRUE; } +/** + * This
