On Thu, 18 Apr 2002 23:37:20 -0400 (EDT) Leif Delgass <[EMAIL PROTECTED]> wrote:
> I can provide some background on this, since I played around with the > locks back when Manuel was working on this. First off, it'll probably be > most productive to work on this on the new branch, when all the register > programming and DMA will be in the DRM. However, a good start could be > made by investigating and hacking on the current branch too. OK, I checked the mach64-0-0-4-branch out tonight and compiled it. It runs surprisingly usable. The only big difference to mach64-0-0-3 which I noticed is that all the CPU load is in the kernel now :) > There are locks in place in aticonsole.c for vt/mode switches > (xc/programs/Xserver/hw/xfree86/drivers/ati) and in atimach64.c for the > XAA functions. The disabled code to initialize 2D acceleration is in > ATIMach64AccelInit() in atimach64.c. I guess the first thing to do is to > make sure that the locks are in the right place, and that the 2D driver's > state is restored correctly. Currently, if a GL context is active, a vt > or mode switch will cause a lockup on returning to the X server > (ATIEnterVT and ATISwitchMode). Also dragging a window or other XAA Ok, I checked aticonsole.c. The existing locks seem to be in the right places. If I understand the problem correctly I will have to make sure that the hardware is in 2d state when the X-server has the lock. This means that it has to check whether it had the lock before. Only if not it will have to restore 2d state. This mechanism could look similar to LOCK_HARDWARE and mach64GetLock in mach64_lock.[ch]. > accelerated actions will cause a lockup. These lockups will likely > require a reboot, but you may be a able to kill the X server remotely if > you're lucky. :) I can say from experience that debugging this can be > frustrating and time-consuming. While r128 and radeon driver code can be > a useful reference, it's important to realize that they have command > engines that are quite different from mach64. As I mentioned before, I don't have another machine to do this. But maybe I can build a simple input device which is not used by X to trigger a background process to kill the X-server. > At any rate, if anyone is interested in helping out and has the time -- > read Jose's developer FAQ, have a look at the code, post questions and > results to the list, and try to drop in on the Monday IRC meetings when > you get the chance. Any help you can provide would be greatly > appreciated. > > -- > Leif Delgass > http://www.retinalburn.net Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ [EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
msg04076/pgp00000.pgp
Description: PGP signature
