From owner-freebsd-hackers Thu Feb 20 04:02:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA08403 for hackers-outgoing; Thu, 20 Feb 1997 04:02:34 -0800 (PST) Received: from ravenock.cybercity.dk (ravenock.cybercity.dk [194.16.57.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA08396 for ; Thu, 20 Feb 1997 04:02:29 -0800 (PST) Received: (from sos@localhost) by ravenock.cybercity.dk (8.8.5/8.7.3) id NAA02849; Thu, 20 Feb 1997 13:04:03 +0100 (MET) From: Søren Schmidt Message-Id: <199702201204.NAA02849@ravenock.cybercity.dk> Subject: Re: Screen flickering In-Reply-To: <199702201042.VAA30639@godzilla.zeta.org.au> from Bruce Evans at "Feb 20, 97 09:42:49 pm" To: bde@zeta.org.au (Bruce Evans) Date: Thu, 20 Feb 1997 13:04:02 +0100 (MET) Cc: brian@awfulhak.demon.co.uk, hackers@freebsd.org, brian@utell.co.uk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Bruce Evans who wrote: > Disabling interrupts for a long time is unacceptable for a multitasking > OS. The problem can be handled "right" if the video card can generate > vertical retrace interrupts: > > 1. Make the vertical retrace interrupt handler a "fast" interrupt > handler so that it has a low latency and can't be interrupted. > Don't use too many other "fast" interrupt handlers, or the > interrupt latency might be too high. > 2. Program the sparkly registers in the vertical retrace interrupt > handler. Do this in less than 20 usec or someone will complain > that the interrupt latency is too high. I'd like to do it this way, but lots of the crappy VGA cards thats out there (and often its the same ones that produces most of the annoing jitter) doesn't support an interrupt, and some only allows using NMI. However it is quite easy to implement, so..... > Busy-waiting for a long time like this (average almost 1/70 seconds) > is also unacceptable for a multitasking OS. This method also takes a > lot of code. It can probably be improved at the cost of even more code > by recording timestamps instead of interrupt counts. Then it could tell > that it was only interrupted for 50 usec (say), so there must be plenty of > time before the retrace completes, so the "go to step 1" step is unnecessary. I dont think this is the way to go, its much too complicated to be worht it. I even have a couble of cards that sometimes "forgets" to flip the status bits on retrace, but they do generate an interrupt :( I guess I should be looking at implementing support for using the interrupt if its there.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end ..