Re: [Dri-devel] DRI observations

[Nathan H. <na...@ma...>]

On Sun, Jan 28, 2001 at 11:24:54PM -0800, David S. Miller wrote:
> 
> Gareth Hughes writes:
>  > I have the same input lag on a box with 128MB RAM, running Q3 on a
>  > 640x480 desktop with no window manager, with no disk activity at all. 
>  > He may very well be suffering from that, but I'm not.
> 
> I basically play Quake3 more than I would care to admit. :-)

You're only human. Quake3 is lots of fun!

> And basically for anyone who plays seriously, xfree86-4.0.x's
> mouse/keyboard response is simply unacceptable.  It makes the
> Linux version of q3a look real bad, because most new people trying out
> Linux q3a today are doing so using xf86-4.0.x.  I've heard everything
> from "wow this feels like crap compared to win32" to "wow linux's q3a
> suck big donkey dick" etc. :-)
> 
> Simple test:
> 
> 1) Bring down q3a console
> 2) Tell it something like "/devmap q3dm1"
> 3) With nothing else going on, move the mouse physically as smoothly as
>   possible from left to right, watch the screen and notice the jitter
>   when using 4.0.x
 
I've just done some (subjective) tests. With in_dgamouse=0 and q3dm1
when you spin around the sequence jerks badly. It seems that changes
in framerate correspond to corrupted mouse events. The quake3 README 
says non-DGA mouse input is achieved using grab and warp. If there's
a significant delay (eg, texture uploads) then the mouse cursor will
clip inside the grabbed window. Any motion before the next warp will
be lost. This will make the mouse response jerky.

With in_dgamouse=1 and q3dm1 the spinning is perfectly smooth. There
is no jerking even when the framerate drops off as the scene changes
in complexity. I tried it just then: it's beautiful.

The strange thing is in_dgamouse was 0 in my config file, completely
at loggerheads with the documentation's claim that the default is to
have in_dgamouse turned on. I don't recall turning it off either.

I can't see how DGA mouse is possibly broken here. I've read through
the code and it is exceptionally simple. Raw mouse events are stolen
by DGA and passed up the wire. They are stuck on the event queue, so
you can't lose mouse events. 

Now a separate issue is that in the quake *menu* the cursor seems to
lag behind your mouse movement. Subjectively it lags equally in both
DGA and non-DGA modes. Perhaps the menu has a 3rd method for getting
motion events. NOTE: it is consistent lag, not jerkiness.

> This does not happen with raw Mesa-3.x on 3dfx cards, which is why
> this is basically the combination I am stuck with even today.
>
> The problem is very real Daryll. :-)

Perhaps, but I can't see it here. If you can't see it, you can't fix
it. It's not like the problem is being ignored. It's just that every
person so far who has seen the problem has gotten amazingly quiet if
asked to help find and fix it.