This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Mar 29 15:23:57 2024 Received: from entropy.muc.muohio.edu (entropy.muc.muohio.edu [134.53.213.10]) by herbie.ucs.indiana.edu (8.8.8/8.8.8) with ESMTP id OAA05589 for ; Sat, 21 Nov 1998 14:09:44 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by entropy.muc.muohio.edu (8.9.0/8.8.7) with ESMTP id OAA08713; Sat, 21 Nov 1998 14:06:29 -0500 Received: by vger.rutgers.edu id <168203-9022>; Sat, 21 Nov 1998 06:54:13 -0500 Received: from xchange.pcgor.com ([206.80.121.161]:61588 "HELO linux.pcgor.com" ident: "TIMEDOUT2") by vger.rutgers.edu with SMTP id <160346-9022>; Fri, 20 Nov 1998 16:36:45 -0500 Received: (qmail 3420 invoked from network); 20 Nov 1998 21:38:55 -0000 Received: from localhost (HELO mindless.com) (menion@127.0.0.1) by localhost with SMTP; 20 Nov 1998 21:38:55 -0000 Message-Id: <3655E16D.837BE930@mindless.com> Date: Fri, 20 Nov 1998 21:38:53 +0000 From: menion X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.1.129 i686) X-Accept-Language: en Mime-Version: 1.0 To: Alex Buell , Linux Kernel Subject: [Fwd: 2.1.129 ? MatroxFB ? Display Corruption] Content-Type: multipart/mixed; boundary="------------84A077F8D9ADA989693D7231" X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu This is a multi-part message in MIME format. --------------84A077F8D9ADA989693D7231 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------84A077F8D9ADA989693D7231 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Delivered-To: menion@cyberhighway.net Received: (qmail 8979 invoked from network); 20 Nov 1998 11:43:53 -0700 Received: from smtp1.cyberhighway.net (qmailr@209.161.0.33) by spool2.cyberhighway.net with SMTP; 20 Nov 1998 11:43:53 -0700 Received: (qmail 12536 invoked from network); 20 Nov 1998 11:21:47 -0700 Received: from lmtp08.iname.net (HELO smv04.globecomm.net) (165.251.8.81) by smtp1.cyberhighway.net with SMTP; 20 Nov 1998 11:21:47 -0700 Return-Path: Received: from zikova.cvut.cz (zikova.cvut.cz [147.32.235.100]) by smv04.globecomm.net (8.9.1a/8.9.0) with ESMTP id NAA02096 for ; Fri, 20 Nov 1998 13:21:44 -0500 (EST) Received: from vcnet.vc.cvut.cz (vcnet.vc.cvut.cz [147.32.240.61]) by zikova.cvut.cz (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id TAA12836 for ; Fri, 20 Nov 1998 19:21:33 +0100 Received: from VCNET/SpoolDir by vcnet.vc.cvut.cz (Mercury 1.21); 20 Nov 98 19:21:34 MET-1MEST Received: from SpoolDir by VCNET (Mercury 1.30); 20 Nov 98 19:21:22 MET-1MEST From: "Petr Vandrovec Ing. VTEI" Organization: CC CTU Prague To: menion Date: Fri, 20 Nov 1998 19:21:22 MET-1 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: 2.1.129 ? MatroxFB ? Display Corruption Priority: normal X-mailer: Pegasus Mail v3.40 Message-ID: <4B126E4B0C@vcnet.vc.cvut.cz> X-Mozilla-Status2: 00000000 > I have 8,16,24, & 32 packed pixel depths compiled in, and I just thought > that I woudl test it. I have not exactly figured out what does it, but > _often_ when I switch VT's, It will present me with skewed chars all ^^^^^^^ only when, I hope. > over the place, and occasionally something from another vt that is > currently displayed. Usually it appears that we are looking at a > virtual screen wider than 80x25, I am looking at a picture of the > center, and getting little peices of several vt's. i.e. 160x50, and I > am looking at the 80x25 image in the center. I hit 'enter' 2 or 3 times > and it clears right up. I can send you .config or any other info > needed. You too, Brutus? Could you download matroxfb.c.gz from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb.c.gz. Version which get to Linus was one of the worstest versions I ever produced. There was for (i = 0; i < 6; i++) hw_extcrt[0] = ecrt[i]; setVGAHardware() extcrt[0] = ecrt[0]; It looked redundant to me, so I removed extcrt[0] = ecrt[0]. But I oversight notice in Matrox manuals that "top of screen is in registers crt[0x0C], crt[0x0D] and extcrt[0x00]. In PowerGraphics mode, changes take effect AFTER write to extcrt[0x00]." So driver in Linus tree sets screen to random position 64KB around right place, sets crt[0x0C] and crt[0x0D] to right value, but did not activate this. YPan procedure is not affected by this bug, if you press enter to scroll screen line up it gets fixed (or shift-pgup/pgdn to scroll back). There is fixed version in vger for more than 3 weeks, but it did not reach Linus yet. Best regards, Petr Vandrovec vandrove@vc.cvut.cz --------------84A077F8D9ADA989693D7231-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/