[Dri-devel] Re: Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On 30 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: On Mon, 2002-01-28 at 15:30, Vladimir Dergachev wrote: On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: On Mon, 2002-01-28 at 10:00, Vladimir Dergachev wrote: On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: On Mon, 2002-01-28 at 04:54, Davor Buvinic wrote: Yes, running glxgears cause the movie player to crawl and if I start to move or resize their windows X crashes. The movie player is MPlayer, today cvs. Here is my log file from X. As you can see, at the end of the file the following messages appears: [...] (II) R128(0): StopVideo (EE) R128(0): Idle timed out, resetting engine... [...] I have an idea what the problem could be. The Xv code still uses direct register access, even when the CCE is running. That's exactly what we want to avoid, because it can crash the chip. :) I probably won't have time this week to work on a solution but I suggest you try either shutting down the CCE before accessing registers or adding new Xv functions which use the CCE for register access (à la the CCE accel functions). I'd prefer not shutting down the CCE at any rate. Yes, that's what happens. I do think we need to shutdown CCE because in some case we want to read registers - and not only write. The short term solution would be to use XAA-Sync() instead of WaitForEngineIdle because WaitForEngineIdle does not guarantee the card is quiscent in CCE mode. Sounds like the correct fix, except I don't even see 'WaitForEngineIdle' in my trees - is that a GATOS novelty? :) Ahh.. sorry it's called XWaitForIdle :)) WaitForEngineIdle is how its called in ATI sample code. Okay, but those aren't either in the Xv code I have, (where) have you added them? http://gatos.sf.net/ - they were there last time I submitted a patch.. but it did not get in. Just to make sure I am not pulling your leg.. Yep, they are there: search for R128WaitForIdle(pScrn) function. Btw, while I've been sleeping I thought how we could get CCE support into Xvideo. The thing I am really against is duplicating code for case with CCE and without. Very much agreed. Eliminating that would also do the 2D acceleration much good, where a lot of functions are exact duplicates for both cases. So, I thought, what about having Software CCE ? I.e. always use CCE commands except that in case when dri driver is not availabe emulate it. I am fairly certain emulating indirect buffer and 2d commands would be pretty easy. I think that's taking it too far (CCE commands are mostly normal register writes or complex commands which can be hard to translate into normal register access), but R128WaitForFifo() and OUTREG() shouldn't be hard to modify such that they use BEGIN_RING(), OUT_RING_REG() and ADVANCE_RING() for the CCE case? Yes, but I would much rather have everything look like CCE, but use OUTREG/INREG when not available. The reason is that a) CCE is really the perfomance case b) It might turn out that emulating CCE in software is faster then usual OUTREGs c) This paves the way for PIO 3d support (i.e. when DMA is not available for some reason) d) this sounds cool e) provides reference implementation.. to check cce behaviour against f) the real problem is not outregs in the code, but INREGs - we'll need to make them CCE aware anyways g) CCE code is actually _cleaner_ than OUTREGs. I know I looked. Vladimir Dergachev -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] chown /dev/dri/card0, system crashes
It's puzzling that chown-chmod would have any baleful effect. With a plain file, once you've opened it you can monkey with the inode all you want and the filehandle remains valid, and similarly with devfs the various device inodes (/dev/misc/psaux, modem TTY, etc.) can be chowned even if, in the case of the mouse, the X-server has it open. At least the kernel module for an OpenGL accellerated card is opened multiple times. A few times when the xserver and the window manager initializes and a few more time for each application that (dynamically) links against the OpenGL lib. So changing file permissions at runtime does affect newly started programs. So you do have multiple clients where some of them must have only user permission. A group based access rights management system is a nice thing if your design is okay. E.g.: - user = group with no X11, no OpenGL - video = group with X11, but no OpenGL - opengl = group with no X11, but OpenGL (thats just my suggestion for the paranoid, typically its caps are included in video) - root = the systems wildcard group A normal user can be made capable of X11 and OpenGL usage by adminstration so that he further joins the respective groups. Alex. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] unsubsrcibed from list
Frank, I've put up a developer FAQ for DRI. It's really just developer oriented so it's complementary to the existing FAQ. In the IRC meeting it was agreed that it should be on the DRI website and its source on CVS. Only the SGML source is on CVS. At this moment I still publicize in it that the most recent version is always available at http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/ . I don't know if in the future we can arrange a way to keep everything in sync and change this. I would like to know what is your opinion about this. Regards, Jose Fonseca On Tue, 2002-01-29 at 04:21, Frank Worsley wrote: Hi all, for some reason I got unsubscribed from the list when SF moved over to their new archives. If there was anything concerning the website that I missed please let me know. In any case, some people have stepped up to give the website a glorious new look. So, maybe in the coming months there will be a new website. I will keep you posted. :) Cheers, - Frank ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On 30 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: On Mit, 2002-01-30 at 10:32, Vladimir Dergachev wrote: On 30 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: Btw, while I've been sleeping I thought how we could get CCE support into Xvideo. The thing I am really against is duplicating code for case with CCE and without. Very much agreed. Eliminating that would also do the 2D acceleration much good, where a lot of functions are exact duplicates for both cases. So, I thought, what about having Software CCE ? I.e. always use CCE commands except that in case when dri driver is not availabe emulate it. I am fairly certain emulating indirect buffer and 2d commands would be pretty easy. I'm not sure it's so easy BTW. Have you looked at what CCE commands are available? I wouldn't want to implement a software emulation, but if you want to, have fun. :) Yes. The fact is you can either DMA them up to CCE engine or write them directly into the FIFO. I think that's taking it too far (CCE commands are mostly normal register writes or complex commands which can be hard to translate into normal register access), but R128WaitForFifo() and OUTREG() shouldn't be hard to modify such that they use BEGIN_RING(), OUT_RING_REG() and ADVANCE_RING() for the CCE case? Yes, but I would much rather have everything look like CCE, but use OUTREG/INREG when not available. The reason is that a) CCE is really the perfomance case b) It might turn out that emulating CCE in software is faster then usual OUTREGs How? The CCE doesn't do anything besides programming registers, does it? Because, for example, we are batching up register transfers. c) This paves the way for PIO 3d support (i.e. when DMA is not available for some reason) Why would one want that? No DMA means no DRM means no DRI. I heard AMD Irongate has problems with DMA and Radeons. DRM still works fine as far as resource control is concerned. d) this sounds cool e) provides reference implementation.. to check cce behaviour against I don't see the use of this either. f) the real problem is not outregs in the code, but INREGs - we'll need to make them CCE aware anyways Are you sure that's a problem at all? IIRC the DRM code reads registers without special precautions about the CCE, but I don't have time to check right now. This depends on which registers you are reading. Some can be read all the time, but some are not. Regardless, many INREGs depend on previous OUTREGs having actually made it to the hardware. Vladimir Dergachev g) CCE code is actually _cleaner_ than OUTREGs. I know I looked. I know I've written some. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On Wed, 30 Jan 2002, Vladimir Dergachev wrote: On 30 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: On Mon, 2002-01-28 at 15:30, Vladimir Dergachev wrote: On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: On Mon, 2002-01-28 at 10:00, Vladimir Dergachev wrote: On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote: On Mon, 2002-01-28 at 04:54, Davor Buvinic wrote: Yes, running glxgears cause the movie player to crawl and if I start to move or resize their windows X crashes. The movie player is MPlayer, today cvs. Here is my log file from X. As you can see, at the end of the file the following messages appears: [...] (II) R128(0): StopVideo (EE) R128(0): Idle timed out, resetting engine... [...] I have an idea what the problem could be. The Xv code still uses direct register access, even when the CCE is running. That's exactly what we want to avoid, because it can crash the chip. :) I probably won't have time this week to work on a solution but I suggest you try either shutting down the CCE before accessing registers or adding new Xv functions which use the CCE for register access (à la the CCE accel functions). I'd prefer not shutting down the CCE at any rate. Yes, that's what happens. I do think we need to shutdown CCE because in some case we want to read registers - and not only write. The short term solution would be to use XAA-Sync() instead of WaitForEngineIdle because WaitForEngineIdle does not guarantee the card is quiscent in CCE mode. Sounds like the correct fix, except I don't even see 'WaitForEngineIdle' in my trees - is that a GATOS novelty? :) Ahh.. sorry it's called XWaitForIdle :)) WaitForEngineIdle is how its called in ATI sample code. Okay, but those aren't either in the Xv code I have, (where) have you added them? http://gatos.sf.net/ - they were there last time I submitted a patch.. but it did not get in. Just to make sure I am not pulling your leg.. Yep, they are there: search for R128WaitForIdle(pScrn) function. I've implemented this (easier than software CCE) scheme. If you want to please try the latest ati.2 CVS code at http://gatos.sf.net - or just take a look at it. Basically I put in info-accel-Sync(pScrn) at entrance points into Xv driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute and PutVideo are all control calls, perfomance is not critical. PutImage should, arguably, take more time during image trasfer.. And if you are playing Quake and watching DVD at the same you are making problems for yourself anyway ;) (And the faster the card the less noticable any slowdown from extra Sync calls will be) Vladimir Dergachev ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500 FAQ was: 2 second question: radeon TL
Does anyone have any news on support for iDCT and Motion-Compensation or any of the video related features of the radeons? Do the reference drivers from ATi have anything for these features? Just curious. Thanks, Alex --- Jose Fonseca wrote: On Mon, 2002-01-28 at 14:17, Jens Owen wrote: ... Perhaps this question could be answer in our new FAQ. I've seen it frequently. Okay. I'll add a summary of what was said in this thread into: Harware / ATI / Radeon 8500 / What are the plans to support this card ? Kevin and Keith, if you know any public resources about this card please give me their links to include in the FAQ as well. ATI seem to release programming information about their products to individuals, rather than make them publicly available. They actually have been making 8500 information available to opensource ppl since prior to the release of the product, and (as I've just learned) have put together a semi-complete reference 3d driver for the card. All this and more is available through their developer relations program. I've got a pretty-close-to-fully-functional tcl driver now, need to do some work on correctness and then look at optimizations. I'd like to get the source out fairly quickly - once it's ok'd by ATI and correct, I'd like to do the final bugfixing tuning on sourceforge. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Radeon 8500 FAQ was: 2 second question: radeon TL
Does anyone have any news on support for iDCT and Motion-Compensation or any of the video related features of the radeons? Do the reference drivers from ATi have anything for these features? Just curious. Thanks, Alex So far i do know, there should be a solution for your problem in the upcoming code. I am not sure if it is open source, but from a clients view its a solution. You might have missed this posting to the list which tells about some other solutions for the 8500 model: -Original Message- From: Vladimir Dergachev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 03:01 To: Jose Fonseca Cc: dri-devel; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Dri-devel] Radeon 8500 FAQ was: 2 second question: radeon TL [...] Code for TV-in support for All-in-Wonder 8500DV is now available from http://gatos.sf.net/ (4.2.0 dash 8 binaries). Vladimir Dergachev ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
Vladimir Dergachev scribbled: __snipped_ I've implemented this (easier than software CCE) scheme. If you want to please try the latest ati.2 CVS code at http://gatos.sf.net - or just take a look at it. Basically I put in info-accel-Sync(pScrn) at entrance points into Xv driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute and PutVideo are all control calls, perfomance is not critical. PutImage should, arguably, take more time during image trasfer.. And if you are playing Quake and watching DVD at the same you are making problems for yourself anyway ;) (And the faster the card the less noticable any slowdown from extra Sync calls will be) I've checked this out. Seems that there is a buggaboo in the radeon implementation. I don't know if the same would apply for R128, seems that it might. from syslog: dernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset call ed without lock held kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start call ed without lock held kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset call ed without lock held kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start call ed without lock held kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held __snipped_it-goes-forever from Xlog: EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 __snipped_it-goes-forever -- Issued as is without warranty of any kind; without even the implied warranty of merchantability or fitness for a particular purpose - GNU General Public License the unofficial official GATOS irc at: irc.openprojects.net #gatos-ati # Ross Coleman - ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] chown /dev/dri/card0, system crashes
On Tue, 29 Jan 2002, Bill Currie wrote: On Tue, Jan 29, 2002 at 04:46:32PM -0800, Jim Carter wrote: However, when the current user did not have permission to write on card0 (due to mode 0660 group video, the default provided by SuSE SaX2) Wouldn't it be better to add the user to group video? That's reasonable on a personal laptop, but in a school computer lab or a cartful of laptops for public checkout, the sysop doesn't really want to have to put every undergrad in the school into group video. (For one thing, there's a nasty limit of 1024 bytes per line in /etc/group, at least on Solaris.) Similarly, for a while about 10 years ago we had a three-headed setup where one CPU served its own video card, plus two other users on X-terminals, and it gave us 30 seats in a lab until we could scrape up the money for something better. The point is, you have to deal with arbitrary users on the console and multiple users on the CPU. The right way to handle it (not available 10 years ago) is for a PAM module (pam_devperm.so) to chown a list of devices to the console user, locking out all others. Specifically from mapping the console user's homework in video RAM. It works for /dev/cdrom, /dev/modem, /dev/mouse, /dev/dsp, /dev/midi0, etc., apparently with no special support in the drivers beyond a generic devfs interface, so why does it break /dev/dri/card0? James F. Carter Voice 310 825 2897FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: [EMAIL PROTECTED]http://www.math.ucla.edu/~jimc (q.v. for PGP key) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
Vladimir Dergachev wrote: On Wed, 30 Jan 2002, deek wrote: Vladimir Dergachev scribbled: __snipped_ I've implemented this (easier than software CCE) scheme. If you want to please try the latest ati.2 CVS code at http://gatos.sf.net - or just take a look at it. Basically I put in info-accel-Sync(pScrn) at entrance points into Xv driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute and PutVideo are all control calls, perfomance is not critical. PutImage should, arguably, take more time during image trasfer.. And if you are playing Quake and watching DVD at the same you are making problems for yourself anyway ;) (And the faster the card the less noticable any slowdown from extra Sync calls will be) I've checked this out. Seems that there is a buggaboo in the radeon implementation. I don't know if the same would apply for R128, seems that it might. GATOS Radeon driver has the proper handling of memory controller. Consequently, usual drm modules will not work - you need to use drm-kernel package available at http://gatos.sf.net/ Vladimir Dergachev Is there any reason the drivers can't be merged? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
Vladimir Dergachev scribbled: On Wed, 30 Jan 2002, deek wrote: Vladimir Dergachev scribbled: __snipped_ I've implemented this (easier than software CCE) scheme. If you want to please try the latest ati.2 CVS code at http://gatos.sf.net - or just take a look at it. Basically I put in info-accel-Sync(pScrn) at entrance points into Xv driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute and PutVideo are all control calls, perfomance is not critical. PutImage should, arguably, take more time during image trasfer.. And if you are playing Quake and watching DVD at the same you are making problems for yourself anyway ;) (And the faster the card the less noticable any slowdown from extra Sync calls will be) I've checked this out. Seems that there is a buggaboo in the radeon implementation. I don't know if the same would apply for R128, seems that it might. GATOS Radeon driver has the proper handling of memory controller. Consequently, usual drm modules will not work - you need to use drm-kernel package available at http://gatos.sf.net/ Come on Vladimir, I'm not green. :-P I even checked out a fresh CVS copy of ati.2 and drm-kernel to make sure that none of my hacks could have been at fault. with that in mind, and the GATOS-radeon.o in the correct place (verified) I rebooted, because I had to, still; same affect. Vladimir Dergachev from syslog: dernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset call ed without lock held kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start call ed without lock held kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset call ed without lock held kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start call ed without lock held kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held __snipped_it-goes-forever from Xlog: EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 __snipped_it-goes-forever -- Issued as is without warranty of any kind; without even the implied warranty of merchantability or fitness for a particular purpose - GNU General Public License - ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On Wed, 30 Jan 2002, deek wrote: Vladimir Dergachev scribbled: On Wed, 30 Jan 2002, deek wrote: Vladimir Dergachev scribbled: __snipped_ I've implemented this (easier than software CCE) scheme. If you want to please try the latest ati.2 CVS code at http://gatos.sf.net - or just take a look at it. Basically I put in info-accel-Sync(pScrn) at entrance points into Xv driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute and PutVideo are all control calls, perfomance is not critical. PutImage should, arguably, take more time during image trasfer.. And if you are playing Quake and watching DVD at the same you are making problems for yourself anyway ;) (And the faster the card the less noticable any slowdown from extra Sync calls will be) I've checked this out. Seems that there is a buggaboo in the radeon implementation. I don't know if the same would apply for R128, seems that it might. GATOS Radeon driver has the proper handling of memory controller. Consequently, usual drm modules will not work - you need to use drm-kernel package available at http://gatos.sf.net/ Come on Vladimir, I'm not green. :-P I even checked out a fresh CVS copy of ati.2 and drm-kernel to make sure that none of my hacks could have been at fault. with that in mind, and the GATOS-radeon.o in the correct place (verified) I rebooted, because I had to, still; same affect. I just updated my ati.2 and I too am getting this lockup. I updated drm-kernel after that as well, to make sure I was in sync and tested again and I am seeing this lockup with it too. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
Come on Vladimir, I'm not green. :-P My bad,.. correct code turned out not to work.. Especially if you commit without testing (I had 8500DV board in). Could you please try again ? Vladimir Dergachev I even checked out a fresh CVS copy of ati.2 and drm-kernel to make sure that none of my hacks could have been at fault. with that in mind, and the GATOS-radeon.o in the correct place (verified) I rebooted, because I had to, still; same affect. Vladimir Dergachev from syslog: dernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset call ed without lock held kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start call ed without lock held kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset call ed without lock held kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start call ed without lock held kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held __snipped_it-goes-forever from Xlog: EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 __snipped_it-goes-forever -- Issued as is without warranty of any kind; without even the implied warranty of merchantability or fitness for a particular purpose - GNU General Public License - ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On Wed, Jan 30, 2002 at 02:05:42PM -0500, Vladimir Dergachev wrote: Regardless of the way it is merged the driver major version will need to be bumped. GATOS drivers does this but only minor - as I did not want to upload a mesa radeon driver just because of the version change. I'm afraid I haven't been following this discussion closely enough, but I found this statement sort of odd, so I thought I'd comment. Version numbers for kernel interfaces are rather different than those for normal software packages. In normal software packages they are more of a vanity thing. A minor version number bump means small things changed, and a major one means hey we did big things. In kernel drivers they are really important as they describe the API between the kernel and the user space application. There are very strict rules about which version numbers are changed when. The major version of a driver should be incremented if and only if there are incompatible changes to the driver that prevent older versions from working. You obviously want to minimize these sorts of changes, so that you don't break compatability. For example, lets say we found a big security hole in an IOCTL. The first thing we'd try to do is rewrite the function so avoid the hole. Maybe even in a way that's really slow. As long as the interface remains the same that's fine. We might add a new interface that's fast again, but keep the old one around for backward compatability. If that's completely impossible then we remove the IOCTL and bump the major version number. If you add or change functionality, but the old drivers still work, then a minor version number should be bumped. Drivers will check for a matching major number and minor number that is greater than or equal to the one they need. So, again if we go back to that security problem. If we rewrote the old IOCTL to be slow but secure and added a new one that is safe and fast, the minor number would be bumped. If you just fix a bug or make some really small change that doesn't impact the interface, then you bump the third digit. Third digits are ignored by the software and are really just documentation. (These paragraphs might be good for a FAQ/Doc somewhere) So, the thing that struck me as odd, is that you said you only bumped the minor version because you didn't want to break Mesa. If your changes do work with Mesa, than bumping the minor version is the right thing to do. We're trying REALLY hard not to change the kernel interfaces. Linus kicked our asses pretty severely about not being careful with kernel version numbers. (Rightfully so) Weve been told in no uncertain terms that if we didn't get this stuff under control it would be removed from the kernel tree. So we should be very careful about how this Gatos functionality is added. It sounds like it should be possible to do it without breaking the API if we put our thinking caps on. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
Vladimir Dergachev scribbled: Come on Vladimir, I'm not green. :-P My bad,.. correct code turned out not to work.. Especially if you commit without testing (I had 8500DV board in). You're fogiven, this time... Could you please try again ? Vladimir Dergachev I even checked out a fresh CVS copy of ati.2 and drm-kernel to make sure that none of my hacks could have been at fault. with that in mind, and the GATOS-radeon.o in the correct place (verified) I rebooted, because I had to, still; same affect. Vladimir Dergachev from syslog: dernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset call ed without lock held kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start call ed without lock held kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held kernel: [drm:radeon_cp_reset] *ERROR* radeon_cp_reset call ed without lock held kernel: [drm:radeon_cp_start] *ERROR* radeon_cp_start call ed without lock held kernel: [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held __snipped_it-goes-forever from Xlog: EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP idle -1007 (EE) RADEON(0): Idle timed out, resetting engine... (EE) RADEON(0): RADEONCPWaitForIdle: CP reset -1007 (EE) RADEON(0): RADEONCPWaitForIdle: CP start -1007 __snipped_it-goes-forever -- Issued as is without warranty of any kind; without even the implied warranty of merchantability or fitness for a particular purpose - GNU General Public License - ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Daryll Strauss wrote: On Wed, Jan 30, 2002 at 02:05:42PM -0500, Vladimir Dergachev wrote: Regardless of the way it is merged the driver major version will need to be bumped. GATOS drivers does this but only minor - as I did not want to upload a mesa radeon driver just because of the version change. I'm afraid I haven't been following this discussion closely enough, but I found this statement sort of odd, so I thought I'd comment. Version numbers for kernel interfaces are rather different than those for normal software packages. In normal software packages they are more of a vanity thing. A minor version number bump means small things changed, and a major one means hey we did big things. In kernel drivers they are really important as they describe the API between the kernel and the user space application. There are very strict rules about which version numbers are changed when. The major version of a driver should be incremented if and only if there are incompatible changes to the driver that prevent older versions from working. You obviously want to minimize these sorts of changes, so that you don't break compatability. For example, lets say we found a big security hole in an IOCTL. The first thing we'd try to do is rewrite the function so avoid the hole. Maybe even in a way that's really slow. As long as the interface remains the same that's fine. We might add a new interface that's fast again, but keep the old one around for backward compatability. If that's completely impossible then we remove the IOCTL and bump the major version number. If you add or change functionality, but the old drivers still work, then a minor version number should be bumped. Drivers will check for a matching major number and minor number that is greater than or equal to the one they need. So, again if we go back to that security problem. If we rewrote the old IOCTL to be slow but secure and added a new one that is safe and fast, the minor number would be bumped. If you just fix a bug or make some really small change that doesn't impact the interface, then you bump the third digit. Third digits are ignored by the software and are really just documentation. I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the slightly broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Vladimir Dergachev (These paragraphs might be good for a FAQ/Doc somewhere) So, the thing that struck me as odd, is that you said you only bumped the minor version because you didn't want to break Mesa. If your changes do work with Mesa, than bumping the minor version is the right thing to do. We're trying REALLY hard not to change the kernel interfaces. Linus kicked our asses pretty severely about not being careful with kernel version numbers. (Rightfully so) Weve been told in no uncertain terms that if we didn't get this stuff under control it would be removed from the kernel tree. So we should be very careful about how this Gatos functionality is added. It sounds like it should be possible to do it without breaking the API if we put our thinking caps on. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the slightly broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Sure does, but it sounds like we could change the Mesa drivers to have the same behavior as the GATOS drivers. If they see version x.y they use the old offset for AGP and if they see x.y+1 they use the new one. This would be much better than bumping the major version number. I may be glossing over details, in fact I probably am, but putting some effort into this is probably required if we want to be good Linux citizens. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Daryll Strauss wrote: On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the slightly broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Sure does, but it sounds like we could change the Mesa drivers to have the same behavior as the GATOS drivers. If they see version x.y they use the old offset for AGP and if they see x.y+1 they use the new one. This would be much better than bumping the major version number. I may be glossing over details, in fact I probably am, but putting some effort into this is probably required if we want to be good Linux citizens. That's a good idea.. Except that it wont' work. Mesa driver is distributed with XFree86 anyway, so when GATOS patch gets merged in everything will work ok. The problem is that I don't know how drm driver can check the version of 2d driver that attempts to initialize it - if you know how please let me know. Without this, first thing after we include mew drm driver into Linux kernel we'll have people downloading it and getting a lockup with 4.2.0 or earlier. Vladimir Dergachev - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
Daryll Strauss wrote: On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the slightly broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Sure does, but it sounds like we could change the Mesa drivers to have the same behavior as the GATOS drivers. If they see version x.y they use the old offset for AGP and if they see x.y+1 they use the new one. This would be much better than bumping the major version number. I may be glossing over details, in fact I probably am, but putting some effort into this is probably required if we want to be good Linux citizens. Daryll, wake up to what you're saying. How daft to suggest this without considering the consequences after all the discussions about backwards compatibility we've had. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
Vladimir Dergachev wrote: On Wed, 30 Jan 2002, Daryll Strauss wrote: On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the slightly broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Sure does, but it sounds like we could change the Mesa drivers to have the same behavior as the GATOS drivers. If they see version x.y they use the old offset for AGP and if they see x.y+1 they use the new one. This would be much better than bumping the major version number. I may be glossing over details, in fact I probably am, but putting some effort into this is probably required if we want to be good Linux citizens. That's a good idea.. Except that it wont' work. Mesa driver is distributed with XFree86 anyway, so when GATOS patch gets merged in everything will work ok. The problem is that I don't know how drm driver can check the version of 2d driver that attempts to initialize it - if you know how please let me know. Without this, first thing after we include mew drm driver into Linux kernel we'll have people downloading it and getting a lockup with 4.2.0 or earlier. It won't be included if it bumps the major number. You need to come up with a way to do this so that old clients *just work*, and new ones do something special to access new functionality. I'd also be wary of assuming that people have the same versions of 2d and 3d drivers installed. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Xpert]XFree86 NDA documentation
On 30 Jan 2002, Jose Fonseca wrote: I've decided to add some pertinent comments from Mike Harris regarding the availability of documentation under NDA to the DRI Devel FAQ ( http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/html/hardware.html#ATI-SPECS ) In the comments Mike makes strong reference to join as XFree86 developer as a mean to obtain NDA documentation that is shared to all XFree86 developers, but it was mentioned in the last IRC meeting that this is no longer true. The fact is that the XFree86 developer page (http://www.xfree.org/developer.html) makes no mention to this and I would like to know if this still holds true or not. At one time, the XFree86 project had some chip docs under NDA and you had to officially become an XFree86 member (join our corporation) to have access to it. Times have changed. I don't know of any documentation that the XFree86 project keeps that isn't available elsewhere. There are still alot of individuals and projects that have NDA'd documentation, but these are not NDAs with the XFree86 Project Inc. XFree86 doesn't really sign NDAs anymore because it hasn't been necessary. Mark. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Keith Whitwell wrote: Vladimir Dergachev wrote: On Wed, 30 Jan 2002, Daryll Strauss wrote: On Wed, Jan 30, 2002 at 02:05:42PM -0500, Vladimir Dergachev wrote: Regardless of the way it is merged the driver major version will need to be bumped. GATOS drivers does this but only minor - as I did not want to upload a mesa radeon driver just because of the version change. I'm afraid I haven't been following this discussion closely enough, but I found this statement sort of odd, so I thought I'd comment. Version numbers for kernel interfaces are rather different than those for normal software packages. In normal software packages they are more of a vanity thing. A minor version number bump means small things changed, and a major one means hey we did big things. In kernel drivers they are really important as they describe the API between the kernel and the user space application. There are very strict rules about which version numbers are changed when. The major version of a driver should be incremented if and only if there are incompatible changes to the driver that prevent older versions from working. You obviously want to minimize these sorts of changes, so that you don't break compatability. For example, lets say we found a big security hole in an IOCTL. The first thing we'd try to do is rewrite the function so avoid the hole. Maybe even in a way that's really slow. As long as the interface remains the same that's fine. We might add a new interface that's fast again, but keep the old one around for backward compatability. If that's completely impossible then we remove the IOCTL and bump the major version number. If you add or change functionality, but the old drivers still work, then a minor version number should be bumped. Drivers will check for a matching major number and minor number that is greater than or equal to the one they need. So, again if we go back to that security problem. If we rewrote the old IOCTL to be slow but secure and added a new one that is safe and fast, the minor number would be bumped. If you just fix a bug or make some really small change that doesn't impact the interface, then you bump the third digit. Third digits are ignored by the software and are really just documentation. I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. This will never be accepted by Linus, Alan or any of the kernel people. You need to find a way to make existing (distributed) clients work with the new kernel modules. Major number bumps are essentially illegal - we've promised not to do this. I don't know how to achieve your changes under that restriction... Is there a way to check from within drm module which 2d driver is accessing it ? Because otherwise we'll need to bump the major version. At the moment 4.2.0 radeon driver will happily work with any drm driver as long as major is the same and minor is not less than what we currently have. The change is not only to make GATOS drivers work, it is needed to make any kind of busmaster PCI access work with AGP Radeons. In particular, scratch register image will not be reliably updated without it. The reason GATOS driver needs it is to perform video capture. Vladimir Dergachev Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Keith Whitwell wrote: Vladimir Dergachev wrote: On Wed, 30 Jan 2002, Daryll Strauss wrote: On Wed, Jan 30, 2002 at 03:15:53PM -0500, Vladimir Dergachev wrote: I completely agree with you.. but I did not give you details :)) What happens is that if you try to use older drm driver with GATOS 2d driver the GATOS driver will notice and complain. But if you use GATOS drm driver with older 4.2.0 2d driver you will get a lockup. The reason is that the changes involve programming Radeon's memory controller to place AGP aperture after the end of the framebuffer and not at the start of PCI space as it is done currently. Both 2d driver and drm driver have to agree on this - which is why a bump in major version is necessary. The reason I did not do it is that the mesa driver checks major version as well. Hence it will complain if it is bumped. Since I did not want to open a new CVS module just for changing version in mesa driver I decided to go the slightly broken way under assumption that few people with install GATOS drm-kernel but will forget to install GATOS 2d driver. Does this make sense ? Sure does, but it sounds like we could change the Mesa drivers to have the same behavior as the GATOS drivers. If they see version x.y they use the old offset for AGP and if they see x.y+1 they use the new one. This would be much better than bumping the major version number. I may be glossing over details, in fact I probably am, but putting some effort into this is probably required if we want to be good Linux citizens. That's a good idea.. Except that it wont' work. Mesa driver is distributed with XFree86 anyway, so when GATOS patch gets merged in everything will work ok. The problem is that I don't know how drm driver can check the version of 2d driver that attempts to initialize it - if you know how please let me know. Without this, first thing after we include mew drm driver into Linux kernel we'll have people downloading it and getting a lockup with 4.2.0 or earlier. It won't be included if it bumps the major number. You need to come up with a way to do this so that old clients *just work*, and new ones do something special to access new functionality. I'd also be wary of assuming that people have the same versions of 2d and 3d drivers installed. The assumption was only made for experimental GATOS drivers. It is a practical one. More people come and ask: I upgraded to GATOS driver and DRI won't work anymore ! Answer: RTFM, upgrade drm driver. Vladimir Dergachev Keith ___ Gatos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gatos-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
The assumption was only made for experimental GATOS drivers. It is a practical one. More people come and ask: I upgraded to GATOS driver and DRI won't work anymore ! Answer: RTFM, upgrade drm driver. It's already been determined that: I just upgraded my kernel, and DRI won't work anymore! RTFM, upgrade your X server I just upgraded my X server, and DRI doesn't work anymore! RTFM, upgrade your kernel just doesn't cut it. You aren't allowed to do anything that requires a response of RTFM, upgrade ... Start thinking of alternatives... -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, 30 Jan 2002, Gareth Hughes wrote: The assumption was only made for experimental GATOS drivers. It is a practical one. More people come and ask: I upgraded to GATOS driver and DRI won't work anymore ! Answer: RTFM, upgrade drm driver. It's already been determined that: I just upgraded my kernel, and DRI won't work anymore! RTFM, upgrade your X server I just upgraded my X server, and DRI doesn't work anymore! RTFM, upgrade your kernel just doesn't cut it. You aren't allowed to do anything that requires a response of RTFM, upgrade ... Start thinking of alternatives... Gareth, the current driver is broken. If someone wants to use video capture they _need_ both GATOS 2d driver and GATOS drm driver, period. What's so wrong about upgrading ? Also, I can make drm driver work nice with older 2d drivers - as soon as someone will show me a way to tell the version of the 2d driver that is accessing the drm driver. best Vladimir Dergachev -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andp ossibly radeonDMA functions
Gareth, the current driver is broken. If someone wants to use video capture they _need_ both GATOS 2d driver and GATOS drm driver, period. What's so wrong about upgrading ? Guaranteed, someone will get a mismatch -- your changes may go back into the stock kernel, breaking DRI CVS or whatever, who knows. Forcing everyone to upgrade their kernel, 2D and 3D drivers to the right magic revision is a recipe for disaster, one that the kernel people have already kicked our arses over (rightly so). Also, I can make drm driver work nice with older 2d drivers - as soon as someone will show me a way to tell the version of the 2d driver that is accessing the drm driver. Sounds like it'll need a 2D driver upgrade :-) -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Radeon 8500 FAQ was: 2 second question: radeon TL
On Wed, 30 Jan 2002, Alexander Stohr wrote: Does anyone have any news on support for iDCT and Motion-Compensation or any of the video related features of the radeons? Do the reference drivers from ATi have anything for these features? Just curious. Thanks, Alex So far i do know, there should be a solution for your problem in the upcoming code. I am not sure if it is open source, but from a clients view its a solution. Just to clarify, GATOS code is open and the driver is under X license. But you are right, the sample iDCT/MC library that ATI is giving out to developers under NDA is binary only, though they do seem to give permission to copy it. It is a start.. Vladimir Dergachev You might have missed this posting to the list which tells about some other solutions for the 8500 model: -Original Message- From: Vladimir Dergachev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 03:01 To: Jose Fonseca Cc: dri-devel; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Dri-devel] Radeon 8500 FAQ was: 2 second question: radeon TL [...] Code for TV-in support for All-in-Wonder 8500DV is now available from http://gatos.sf.net/ (4.2.0 dash 8 binaries). Vladimir Dergachev ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] unsubsrcibed from list
Ok, I will just put a link from the Documentation page to your website. That way you can just update the docs on your end. Is that ok? It would also be nice if the IRC meeting logs were available on the website. The easiest way would probably be to add a new FAQ section for that and add every new log as as question titled IRC Log from date. The first question in that section should probably be the schedule when the meetings take place. Anybody who attends the meetings and wants to post the logs let me know. - Frank On Wed, 2002-01-30 at 05:52, Jose Fonseca wrote: Frank, I've put up a developer FAQ for DRI. It's really just developer oriented so it's complementary to the existing FAQ. In the IRC meeting it was agreed that it should be on the DRI website and its source on CVS. Only the SGML source is on CVS. At this moment I still publicize in it that the most recent version is always available at http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/ . I don't know if in the future we can arrange a way to keep everything in sync and change this. I would like to know what is your opinion about this. Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andp ossibly radeonDMA functions
On Wed, 30 Jan 2002, Gareth Hughes wrote: Gareth, the current driver is broken. If someone wants to use video capture they _need_ both GATOS 2d driver and GATOS drm driver, period. What's so wrong about upgrading ? Guaranteed, someone will get a mismatch -- your changes may go back into the stock kernel, breaking DRI CVS or whatever, who knows. Forcing everyone to upgrade their kernel, 2D and 3D drivers to the right magic revision is a recipe for disaster, one that the kernel people have already kicked our arses over (rightly so). Also, I can make drm driver work nice with older 2d drivers - as soon as someone will show me a way to tell the version of the 2d driver that is accessing the drm driver. Sounds like it'll need a 2D driver upgrade :-) So what are you proposing ? Not to fix it ? We have a system where a driver is split in three components all of which have to agree on the hardware state. There is just so much you can do for backward compatibility. You can do less if you can't find one component version from another one. As for Linus not wanting to accept it, 2.4 has dropped most nat filters except for ftp and most of them aren't back yet. So I don't buy this argument. Vladimir Dergachev -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] All those parties... Mach64 non AGP DRI support?
I dont know if this is coming, or if there's any interest. But X just *dies* using the CPU to redraw 2D and 3D just isn't even worth using on this P200. I have a Mach64 chipset: ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB There is no DRI support for this card (at the moment). Is there anyone out there working on such a driver? I'm sure a lot of us users would be very happy ;) Shawn. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] All those parties... Mach64 non AGP DRI support?
On Wed, 30 Jan 2002, Shawn Starr wrote: I dont know if this is coming, or if there's any interest. But X just *dies* using the CPU to redraw 2D and 3D just isn't even worth using on this P200. I have a Mach64 chipset: ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB There is no DRI support for this card (at the moment). Is there anyone out there working on such a driver? I'm sure a lot of us users would be very happy ;) I do not have GT, but I do have GTB (Rage II+DVD) and X seem to work ok with it. Are you using KDE by any chance ? Something in it (lots of eye candy I bet) manages to slow down even the fastest cards. Why don't you try twm first and see if it is any better. Next try Enlightenment.. I suggest Blue Metal scheme as it is less pixmap intensive. Also reducing your resolution to 640x480 might speed up things as well. Vladimir Dergachev Shawn. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xpert]RE: [Dri-devel] Re: [GATOS]Re: Bugfix for br0ken DMA on r128 andpossibly radeonDMA functions
On Wed, Jan 30, 2002 at 08:27:49PM -0700, Jens Owen wrote: | This is no joke. We absolutely need compatability. Large amounts of | developer pain don't even begin to compare to the enormous number of | headaches incompatability causes our users. Not to mention that Linus will almost certainly throw DRM out of the kernel if we don't maintain compatibility (or at least a versioning system that detects incompatibilities and falls back to a previously-supported configuration). Allen ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] All those parties... Mach64 non AGP DRI support?
GNOME 1.4.x still, but running TuxRacer totally blew up X/system. I compared this to win2k and it just blew it out of the water HARD :( On Wed, 30 Jan 2002, Vladimir Dergachev wrote: On Wed, 30 Jan 2002, Shawn Starr wrote: I dont know if this is coming, or if there's any interest. But X just *dies* using the CPU to redraw 2D and 3D just isn't even worth using on this P200. I have a Mach64 chipset: ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB There is no DRI support for this card (at the moment). Is there anyone out there working on such a driver? I'm sure a lot of us users would be very happy ;) I do not have GT, but I do have GTB (Rage II+DVD) and X seem to work ok with it. Are you using KDE by any chance ? Something in it (lots of eye candy I bet) manages to slow down even the fastest cards. Why don't you try twm first and see if it is any better. Next try Enlightenment.. I suggest Blue Metal scheme as it is less pixmap intensive. Also reducing your resolution to 640x480 might speed up things as well. Vladimir Dergachev Shawn. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
