On Wed, 20 Oct 1999, Jon M. Taylor wrote:
> On Wed, 20 Oct 1999, [iso-8859-1] Rub�n wrote:
>
> > On 1999/Oct/20, Brian S. Julin wrote:
> >
> > > Basically there are two situations to worry about. One is trying
> > > to find the ray position from userspace when the process is running.
> > > The other is trying to get the scheduler to run the process
> > > promptly at a certain ray positions.
> >
> > I think there is an easy solution for the first thing. Why don't you
> > share a flag variable between the kernel and the process, that becomes 1 at
> > the vertical retrace and 0 when it finishes? It would be for programmers
> > even more efficient than reading from the IO port directly (which is
> > impossible under Linux, obviously). It could be managed in a similar way
> > than the graphics context, couldn't it?
>
> I think that putting this flag in the context map is the way to
> go. The flag can be quickly toggled by the interrupt handler, and nothing
> else is necessary. This doesn't get around the scheduling Hz problem, but
> that is a separate issue anyway, and needs to be fixed for a lot more than
> just GGI.
This is sort of what I intend, however, more than a simple IRQ driven
flag, because, as I said in the previous e-mail, anything IRQ driven will
miss/waste the front porch entirely.
Right now I have a stand-alone system so I can develop without
entanglement in the GGI source tree; it is a module implementing
an MMAPable /proc/rt page that is altered by the kernel. The page is
altered by a configurable combination of an IRQ handler, a standard linux
periodic task, or a user-space initiated IOCTL. The routine is always
the same: store the TSC, read a value from the card, store the TSC
again. That way, userspace will be able to calculate a formula that will
get a pretty accurate value for WaitRayPos based on the value of the
processor TSC register, and that means finding out the ray position
using a very few cycles and no context switch.
For chipsets that have line counters and such goodies this is very simple,
but I'm cracking the toughest nut (VGA retrace detect bits only) first.
This involves convergence of a frequency detection algorithm that is working
with data taken at more or less random time locations, and it has defied
my first few naive attempts. Still I am confident when I find time to finish
it that I can get it to converge on most systems pretty quickly. It should
be pretty easy to hook into LibGGIMisc once I'm done; the only potential
snag I see is somehow hooking it so whenever a SetMode or console switch-to
happens the userspace code that recalibrates gets called. KGI metalanguages
should make short work of the kernel side of the code.
--
Brian
P.S. Actually the toughest nut would be if I was using the CTC via IOCTL,
or working on a system with a variable/halting TSC register, but for now
I'm assuming the TSC is there and constant.
