> On Fri, Sep 13, 2002 at 09:01:24AM -0700, Charles C. Fu wrote: >> So, defaulting to a software cursor on Trident systems may be unsafe >> for some systems. Discussing the problem in the trident(4) man page >> and elsewhere would still be good.
In <[EMAIL PROTECTED]> on 13 Sep 2002, G. Branden Robinson <[EMAIL PROTECTED]> wrote: > Please send all your comments upstream to [EMAIL PROTECTED], so that > the driver maintainer, Alan Hourihane, can see them. Well, since they were long and some of the info already known, I'll just summarize here, incorporate some new information, and refer interested parties to <URL:http://bugs.debian.org/155291> for detailed symptoms, logs, system info, and so forth. The Symptoms ------------ A Linux system with a Trident CyberBlade/i1 card (8MB) running 4.1.0.1 exhibits both of the following problems: - (NEW bug report?) When more than 4MB of video RAM is used, the monitor displays a blue screen or goes into and thereafter stays in power save mode. Logs give no indication that anything is wrong. - Symptoms sound much like this svgalib bug report <URL:http://www.arava.co.il/matan/svgalib/hypermail/1769.html> about the same card causing the monitor to go to sleep if higher res modes are attempted. - Also, running an X server with 4MB and then starting a second with 8MB on another virtual terminal can cause both to exhibit the power save behavior. There appears to be no way to recover short of killing both servers. - This blue screen/power save mode lock-in problem occurs regardless of whether a hardware or software cursor is used. - Sorry, I do not know if the monitor is sent into standby, suspend, or off state. I don't see a discussion of this problem in a quick search of the Xpert archives nor is it clear from the current source code that this problem is known, so this may be a new bug report. From a reading through the source code, I expect this problem is still present. - (Widely reported, both on Xpert and elsewhere) Using the hardware cursor, certain Trident cards, not just this particular model, can result in the cursor suddenly and unrecoverably shifting off a few pixels to the right of the true mouse position. In the current source code in CVS (but not the older code used in Debian's stable release), Alan has unconditionally disabled the hardware cursor for this and some other cards to work around this problem. So, with both these problems, X on this box functions stably only if the hardware cursor is disabled AND X is limited to 4MB of video RAM. Note: Only disabling the hardware cursor in XF86Config-4, as some have recommended and as would appear to occur with the current CVS code, is particularly nasty on this system since the driver then thinks it's OK to use ALL the video RAM on the card, resulting in the blue screen/power save mode lock-in. Suggestions ----------- Other people should try to confirm the blue screen/power save mode problem, which is serious in that it results in an unusable X server with at least this card when the hardware cursor is simply turned off (i.e., without also limiting video RAM). Alan indicates in his CVS messages that he will implement a better workaround for the offset problem than simply disabling the hardware cursor. Obviously, that would be great. For now, at the very least, documentation of the cursor offset bug should be added to older branches (e.g., to trident(4)). Better would be to backport the hardware cursor disabling code in conjunction with a workaround for the blue screen/power save mode lock-in problem. -ccwf -- Charles C. Fu ,-- Vice President ___ __ __. . ,-/-- [EMAIL PROTECTED] Bacchus, Inc. (_,(_,|/|/ / http://www.bacchus.com/ Tel/Fax 310-455-2396 ----' _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
