> > > > 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, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message