From owner-freebsd-current Fri Nov 12 1: 4:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (castles544.castles.com [208.214.165.108]) by hub.freebsd.org (Postfix) with ESMTP id A7BC514C38 for ; Fri, 12 Nov 1999 01:04:11 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id AAA00712; Fri, 12 Nov 1999 00:54:50 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199911120854.AAA00712@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Amancio Hasty Cc: current@FreeBSD.ORG Subject: Re: vga driver and signal In-reply-to: Your message of "Thu, 04 Nov 1999 19:05:41 PST." <199911050305.TAA50795@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Nov 1999 00:54:46 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > The only real way to do this "right" is going to be to have the X > > > > server load a KLD, which will then be able to hook the relevant > > > > interrupt(s). Any other alternative involves interrupt delivery to > > > > user-space, which is just not practical. > > > > > > Hi Mike, > > > Your idea sounds intriguing . How should we wired the KLD to > > > the X server? or how will the KLD inform the X server that it > > > has received a vertical retrace interrupt . > > > > The X server would have to load the KLD when it starts. The KLD would > > have to contain _all_ of the code that would run when the interrupt > > triggered. You would still have absolutely no latency guarantee on > > delivery of the interrupt to the KLD; you'd have to check on entry to > > the handler to see whether you weren't already too late. > > > > Basically, the whole idea is just totally screwed. You shouldn't be > > trying to do this because it just can't be done right. > > I should be trying to do this for it can have interesting applications such > as a Tivo player. Not sure what the problem with interrupt latency is ... > Can you elaborate a little bit more ? If you're talking about a specific piece of hardware whose design you are in control of, you can tweak the hardware/software combination to achieve the desired goal. The point I was trying to make was that in the _general_ case, this can't be done with software alone. You require the cooperation of hardware that just can't be obtained from your average PC. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message