I've figured out what was causing the emission of vertexes with humongous coordinates: the vertex_stride_shift wasn't being updated because all mach64 vertex formats (*_VERTEX_FORMAT) were defined to 0, so the vertexes were being overlapped with a step of 1 byte.
I guess that these defines map the vertex formats generated by the template into the vertexes formats recognized by the DRM for DMA buffering purposes. Since this isn't yet implemented on mach64, I've just given sequential numbers to each one of them to force switching the vertex stride. X still hangs when mach64DDPrintDirty (which is called while holding the lock) and the output is redirected to an X terminal - works fine in other cases. Is this something to expect, or is the locking mechanism in DRM not working properly? I guess not, otherwise any malicious client could hang X by doing this. For the time being I just overridden this output. In the meanwhile I've managed another laptop for remote debugging. In fact, I had it with me a day ago, but I wasn't able to setup local networking. It was by mere chance that I read in the web a page about hotplug devices and I noticed then that I was using 168.192.x.x instead 192.168.x.x, as in an example in that page! Stupid me.. 8O What matters is that now I can get the client's stack backtrace when X hangs and things are now like cutting butter! I've just tested with glxgears, and I'll now start testing with several applications. There is no guarantee that the drive is already functional. I've just stopped to commit the changes and announce my progress. Regards, José Fonseca _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
