On Fri, 24 May 2002, José Fonseca wrote:
>
> When doing this you're using the GATOS DRM with the Radeon Mesa & X
> drivers of DRI CVS. Since the regular X works, it seems that GATOS broke
> binary compatibility. Does this happens too when switching GATOS with
> XF-4.2?
Note that once I switch away from Gatos, nothing of Gatos is left behind,
so it's more than a binary compatibility issue: Gatos puts the card in
some state that the DRI tree simply cannot handle. And yes, you don't even
need the DRI branch, you can see the lockup even with gatos -> plain XFree
CVS (I told Keith Packard about it, I haven't heard back).
[ Aside: I haven't tried to used Gatos for any 3D stuff - this
happens even with GLX/DRI not even loaded. ]
The point being that even the tuxracer lockup may not have anything to do
with 3D itself: it may be that the lockup is due to the same (generic XF)
bug, and maybe the 3D pipeline triggers the same card state that Gatos
somehow triggers: the card gets in some "busy" state that needs explicit
help in clearing or something (and just waiting for the busy state to go
away thus ends up being non-productive).
Anyway, it was just a suggestion for an alternate thing to look at that
might be more easily debuggable and _migth_ have common causes.
I piped up just because I wanted to start merging the DRI kernel stuff
into the 2.5.x kernel tree, so I started following the mailing list to see
what the gotcha's are... My actual 3D testing itself is limited to just
verifying that "glxgears" works at 1000 fps, so that I can be reasonably
happy that the merge works to _some_ degree ;)
Linus
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
