Morning Marcel,

> Well, I only noticed 3, none of those running QPC under Windows. And I
> currently do not have any further ideas in this area because the
> things told do not add up:
I agree - I'm impressed that you are still thinking about it to be honest.

<SNIP>

None of the above makes any sense does it! (Sorry, the list of points
you made!). The only thought I have had this morning is that the kernel
cannot be used for any 'real time' processes as it is not, without a
huge patch, real time able.

Windows, for example, can be used in a recoding studio as is, but Linux
cannot. It can when you apply the real time patch, but not relaiable
until then.

I'm wondering if Linux is shceduling QPC 'badly' for some reason, but I
really don't know enough about Kernel programming (yet - but I have a
book!) to say for certain!


> What I should probably have said is that QPC does re-synchronize the
> SMSQ/E clock with the system clock once per minute. So even if the
> clock is runaway fast it will be right again one minute later.
Ah, ok. No problems. I watched it for a while and it kept the same time
as the xclock which was running side by side with it.

<SNIP>

> Therefore my first guess would be that you're using an optical mouse
> that has problems with the surface it's on. 
I had that problem today at work! I have an optical mouse there and I
was changing my monitor for a bigger one and the mouse was placed on a
wooden (effect) desktop instead of the mouse mat.

When the new monitor was fired up, the pointer was wandering all over
the place. Shook the mouse and when it stopped, it carried on moving by
itself. Put the mouse back on the pad - it remained where it was.

Some mouse mats that we were issued with at work have a similar problem
- they are too light coloured (I think) and the optics seem to lose the
plot!


Cheers,
Norman.

_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to