Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=44
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From [EMAIL PROTECTED] 2004-02-02 04:01 -------
Sorry to reopen this guys... many eons after the fact.
I'm running the latest DRI snapshot with the CVS XFree86 binary from AlanH's
website. Here's my XFree86 -version information:
XFree86 Version 4.3.99.16
Release Date: 20 November 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.20-gentoo-r8 i686 [ELF]
Current Operating System: Linux pixelmonkey 2.6.1 #2 SMP Tue Jan 27 19:01:39 EST
2004 i686
Build Date: 03 December 2003
Changelog Date: 02 December 2003
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Since I last commented on this bug, I have switched hardware (except for this
damn ATI card) to an Intel chipset, P4, etc. I have also upgraded to debian sid
and also got my X packages from the X Strike Force's experimental branch.
My DRI snapshot is from February 2nd. I downloaded the AlanH stuff today as well.
Basically, my mode switching problems still exist. I think it's possible this
has fixed the VT Switching problems. But mode switching still causes complete
hard lock on my machine, with no way to recover. As before, when my machine
locks up, monitor goes blank and I can ssh in, but cannot kill XFree86 for the
life of me.
To refresh your memory, the locks are happening when I run a 3D-enabled program
that tries to go fullscreen with a resolution lower than my desktop. i.e. if I
try to run tuxracer at 1024x768 when my desktop is running 1280x1024.
I can, as a workaround, make all 3D programs run at my desktop resolution, and
crashes NEVER occur. But with some things that means horrible performance.
Note that the lock-ups during mode change are erratic. Sometimes they occur,
sometimes they don't. But it's definitely true that usually they do occur.
It's lucky when it doesn't occur. This is the same as before.
So, basically it looks like the CVS modifications and latest work on DRI has
fixed the VT switching problem (I think, I'm kinda afraid to test it
extensively), but the mode switching problems are still there.
Thanks for your time,
Andrew
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
