Highly erratic mouse behavior

[Tom Murphy]

Hi all,

I'm so happy to be able to play Quake 2 again, thanks for making this
available!

I've been using the sdlquake2 binary and it looks really nice.
Unfortunately, my mouse doesn't seem too happy with it. It's very jerky
and hard to control. When I load up quake2, if I move the mouse to the
right, it moves left. If I move the mouse to the left, it moves right.
This is easily fixed by setting m_yaw -0.022 in the console, however,
the mouse movement is extremely jerky and hard to control. I find myself
unable to aim with it.

Are there some things I can try with this?

I'm using an IBM optical mouse (with a glowing blue middle button).
Xorg-X11 v6.8.0-r4
I am not using gpm.

The mouse section of my xorg.conf looks like this:

Section "InputDevice"

Identifier "Mouse1"
Driver "mouse"
Option "CorePointer"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"

EndSection

The mouse is a USB mouse, but it is plugged in to my PS/2 port (it
has one of those USB -> PS/2 converter things on it. Perhaps I should
try direct USB mouse?)

Thanks!

Tom

[Andreas 'GlaDiaC' Schneider]

I have a Logitech MX 510 and it works like a charm. Same on my notebook
with the notbook mouse. Maybe it is the SDL lib...


-- andreas

Post by Tom Murphy
Hi all,
I'm so happy to be able to play Quake 2 again, thanks for making this
available!
I've been using the sdlquake2 binary and it looks really nice.
Unfortunately, my mouse doesn't seem too happy with it. It's very jerky
and hard to control. When I load up quake2, if I move the mouse to the
right, it moves left. If I move the mouse to the left, it moves right.
This is easily fixed by setting m_yaw -0.022 in the console, however,
the mouse movement is extremely jerky and hard to control. I find myself
unable to aim with it.
Are there some things I can try with this?
I'm using an IBM optical mouse (with a glowing blue middle button).
Xorg-X11 v6.8.0-r4
I am not using gpm.
Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "CorePointer"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
EndSection
The mouse is a USB mouse, but it is plugged in to my PS/2 port (it
has one of those USB -> PS/2 converter things on it. Perhaps I should
try direct USB mouse?)
Thanks!
Tom

[Thomas J Fogal]

<20050208130422.GD1100 at yggdrasil.ath.cx>Tom Murphy writes:
<snip>

Post by Tom Murphy
I've been using the sdlquake2 binary and it looks really nice.
Unfortunately, my mouse doesn't seem too happy with it. It's very jerky
and hard to control. When I load up quake2, if I move the mouse to the
right, it moves left. If I move the mouse to the left, it moves right.
This is easily fixed by setting m_yaw -0.022 in the console, however,
the mouse movement is extremely jerky and hard to control. I find myself
unable to aim with it.

This is a known problem that some people see, although I thought (might
have just not been following the thread closely enough...) that it had
been fixed with the latest release.

Anyway, try CVS and/or release 0.15 if you don't need anything thats
been added since then, I believe thats when the mouse started getting
weird.

HTH,

-tom

[Bradley Chapman (TheOneKEA)]

Mr. Murphy,

Post by Tom Murphy
The mouse is a USB mouse, but it is plugged in to my PS/2 port (it
has one of those USB -> PS/2 converter things on it. Perhaps I should
try direct USB mouse?)

You should. I have a Logitech MX700 configured as IMPS/2 in XFree86
and I experience no jerkiness with sdlquake2.

Post by Tom Murphy
Thanks!
Tom

Brad

[Tom Murphy]

Well I've switched the mouse from the PS/2 port (via USB->PS/2 adapter)
to directly into the USB port and the same problem occurs.

I've found if I try to aim and fire, it will lag slightly, and of
course, reacting, I overcompensate and end up moving too far one way or
the other. It's as if the mouse is lagging behind my movements.

I tried m_filter 1 to see if that helped. It didn't.
It doesn't seem to be the sdl binaries, because it does the exact same
thing with just running 'quake 2'. (I have to run the sdl binaries just
so I can have sound.. sound doesn't work otherwise.)

I found that the IBM Scrollpoint mouse gives insane values to X when
using the scroll wheel.
(http://www.ussg.iu.edu/hypermail/linux/kernel/0410.3/0799.html), but I
feel these two items are unrelated. The swap of left and right on the
axis is a bit strange.. and having to set the m_yaw to a negative number
shouldn't be normal, should it? I've also tried changing m_yaw #'s and
it's still acting up.

I'll try 0.15 and see if that works.

Tom

[Asfand Yar Qazi]

Post by Tom Murphy
Well I've switched the mouse from the PS/2 port (via USB->PS/2 adapter)
to directly into the USB port and the same problem occurs.
I've found if I try to aim and fire, it will lag slightly, and of
course, reacting, I overcompensate and end up moving too far one way or
the other. It's as if the mouse is lagging behind my movements.
I tried m_filter 1 to see if that helped. It didn't.
It doesn't seem to be the sdl binaries, because it does the exact same
thing with just running 'quake 2'. (I have to run the sdl binaries just
so I can have sound.. sound doesn't work otherwise.)
I found that the IBM Scrollpoint mouse gives insane values to X when
using the scroll wheel.
(http://www.ussg.iu.edu/hypermail/linux/kernel/0410.3/0799.html), but I
feel these two items are unrelated. The swap of left and right on the
axis is a bit strange.. and having to set the m_yaw to a negative number
shouldn't be normal, should it? I've also tried changing m_yaw #'s and
it's still acting up.
I'll try 0.15 and see if that works.
Tom

Which version are you playing? Also, try the version of quake 2
called 'quake2forge' (http://freshmeat.net/projects/quake2forge/). I
don't like what they've done with their port (putting data files in
'<prefix>/share/games/quake2', binaries in '<share>/bin', video driver
libraries in <prefix>/lib/quake2, use of autoconf/automake etc.) but
you may have some luck with it. Even if you don't, it'll rule out the
possibility that this port's game code is at fault, anyhow.

[Tom Murphy]

Post by Asfand Yar Qazi
Which version are you playing? Also, try the version of quake 2
called 'quake2forge' (http://freshmeat.net/projects/quake2forge/). I
don't like what they've done with their port (putting data files in
'<prefix>/share/games/quake2', binaries in '<share>/bin', video driver
libraries in <prefix>/lib/quake2, use of autoconf/automake etc.) but
you may have some luck with it. Even if you don't, it'll rule out the
possibility that this port's game code is at fault, anyhow.

I'm playing 0.16.1.
I'll give quake2forge a try too!

Thanks,
Tom

[Michel Dänzer]

Post by Tom Murphy
Well I've switched the mouse from the PS/2 port (via USB->PS/2 adapter)
to directly into the USB port and the same problem occurs.
I've found if I try to aim and fire, it will lag slightly, and of
course, reacting, I overcompensate and end up moving too far one way or
the other. It's as if the mouse is lagging behind my movements.

This sounds like it could be caused by the Quake renderer getting too
far ahead of the hardware. Is gl_finish enabled?

[Tom Murphy]

Post by Michel Dänzer

Post by Tom Murphy
Well I've switched the mouse from the PS/2 port (via USB->PS/2 adapter)
to directly into the USB port and the same problem occurs.
I've found if I try to aim and fire, it will lag slightly, and of
course, reacting, I overcompensate and end up moving too far one way or
the other. It's as if the mouse is lagging behind my movements.

This sounds like it could be caused by the Quake renderer getting too
far ahead of the hardware. Is gl_finish enabled?

yes, it is.. I turned it off and the lag got worse.

Tom

[Andreas 'GlaDiaC' Schneider]

Take a look at
http://www.linux-gamers.net/modules/wfsection/article.php?articleid=46

and

http://www.linux-gamers.net/modules/wfsection/article.php?articleid=47


-- andreas

Post by Tom Murphy
Well I've switched the mouse from the PS/2 port (via USB->PS/2 adapter)
to directly into the USB port and the same problem occurs.
I've found if I try to aim and fire, it will lag slightly, and of
course, reacting, I overcompensate and end up moving too far one way or
the other. It's as if the mouse is lagging behind my movements.
I tried m_filter 1 to see if that helped. It didn't.
It doesn't seem to be the sdl binaries, because it does the exact same
thing with just running 'quake 2'. (I have to run the sdl binaries just
so I can have sound.. sound doesn't work otherwise.)
I found that the IBM Scrollpoint mouse gives insane values to X when
using the scroll wheel.
(http://www.ussg.iu.edu/hypermail/linux/kernel/0410.3/0799.html), but I
feel these two items are unrelated. The swap of left and right on the
axis is a bit strange.. and having to set the m_yaw to a negative number
shouldn't be normal, should it? I've also tried changing m_yaw #'s and
it's still acting up.
I'll try 0.15 and see if that works.
Tom

[Tom Murphy]

I've tried both of these and it appears to make no difference.
I'm now convinced it's not lag exactly.
If I move the mouse up/down a bit, or left/right (back and forth)
the result -should be- a smooth up/down or left/right motion.
What I get instead is a stutter effect, where I move the mouse to the
left and it starts to move left, but then it gets stuck at a point and
jitters to the right.

I don't get this behavior on the desktop in X when I move my mouse
around the screen.

Tom

Post by Andreas 'GlaDiaC' Schneider
Take a look at
http://www.linux-gamers.net/modules/wfsection/article.php?articleid=46
and
http://www.linux-gamers.net/modules/wfsection/article.php?articleid=47
-- andreas

Post by Tom Murphy
Well I've switched the mouse from the PS/2 port (via USB->PS/2 adapter)
to directly into the USB port and the same problem occurs.
I've found if I try to aim and fire, it will lag slightly, and of
course, reacting, I overcompensate and end up moving too far one way or
the other. It's as if the mouse is lagging behind my movements.
I tried m_filter 1 to see if that helped. It didn't.
It doesn't seem to be the sdl binaries, because it does the exact same
thing with just running 'quake 2'. (I have to run the sdl binaries just
so I can have sound.. sound doesn't work otherwise.)
I found that the IBM Scrollpoint mouse gives insane values to X when
using the scroll wheel.
(http://www.ussg.iu.edu/hypermail/linux/kernel/0410.3/0799.html), but I
feel these two items are unrelated. The swap of left and right on the
axis is a bit strange.. and having to set the m_yaw to a negative number
shouldn't be normal, should it? I've also tried changing m_yaw #'s and
it's still acting up.
I'll try 0.15 and see if that works.
Tom

[Tom Murphy]

Well the problem appears to lie in the Icculus port. I installed the
quake 2 forge port and the mouse appears to work properly in it.

I'd be glad to help debug this to provide information if it will help
the icculus port. I'm all for building a better beast. :)

-Tom

[Brendan Burns]

Tom,
Just so I properly understand: You see the same problem in 0.15 and
0.16.1 and in both renderers (ref_sdlgl and ref_glx)?

Thanks
--brendan

Post by Tom Murphy
Well the problem appears to lie in the Icculus port. I installed the
quake 2 forge port and the mouse appears to work properly in it.
I'd be glad to help debug this to provide information if it will help
the icculus port. I'm all for building a better beast. :)
-Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2377 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake2/attachments/20050210/273c0d3a/attachment.bin>

[Tom Murphy]

Post by Brendan Burns
Tom,
Just so I properly understand: You see the same problem in 0.15 and
0.16.1 and in both renderers (ref_sdlgl and ref_glx)?
Thanks
--brendan

Hmm.. does quake2-icculus depend on aalib?
I don't seem to get the mouse left/right reversal since I recompiled
0.16.1 (and aalib was installed since then because 0.15 wouldn't
compile w/o aalib.)

What command lines should I be using? I've been using sdlquake2-qmax
because under regular "quake2" the sound is broken.

Tom

[Brendan Burns]

If you set BUILD_AA to no in the Makefile, it doesn't need aalib...

You can change renderers with:

sdlquake2-qmax +set vid_ref sdlgl

or

sdlquake2-qmax +set vid_ref glx

Note that such changes are sticky, e.g. they modify the default value
used in the future
if nothing is specified...

--brendan

Post by Tom Murphy

Post by Brendan Burns
Tom,
Just so I properly understand: You see the same problem in 0.15 and
0.16.1 and in both renderers (ref_sdlgl and ref_glx)?
Thanks
--brendan

Hmm.. does quake2-icculus depend on aalib?
I don't seem to get the mouse left/right reversal since I recompiled
0.16.1 (and aalib was installed since then because 0.15 wouldn't
compile w/o aalib.)
What command lines should I be using? I've been using sdlquake2-qmax
because under regular "quake2" the sound is broken.
Tom

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2377 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake2/attachments/20050210/4af62443/attachment.bin>

[Tom Murphy]

Post by Brendan Burns
If you set BUILD_AA to no in the Makefile, it doesn't need aalib...
sdlquake2-qmax +set vid_ref sdlgl
or
sdlquake2-qmax +set vid_ref glx
Note that such changes are sticky, e.g. they modify the default value
used in the future
if nothing is specified...
--brendan

OK under sdlgl it runs fine, mouse works properly and everything.
Under glx, it's screwed up as before.

I think that's why the other quake 2 ran OK.. it was under all SDL mode.

Tom

[Anders Storsveen]

I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.

I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.

If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.

If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!

It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Post by Tom Murphy

Post by Brendan Burns
If you set BUILD_AA to no in the Makefile, it doesn't need aalib...
sdlquake2-qmax +set vid_ref sdlgl
or
sdlquake2-qmax +set vid_ref glx
Note that such changes are sticky, e.g. they modify the default value
used in the future
if nothing is specified...
--brendan

OK under sdlgl it runs fine, mouse works properly and everything.
Under glx, it's screwed up as before.
I think that's why the other quake 2 ran OK.. it was under all SDL mode.
Tom

[Julien Langer]

Post by Anders Storsveen
I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.
I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.
If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.
If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!
It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Hi,
I don't see such a behavior on my machine.
No matter how fast I move the mouse, the distance it covers is always
the same... in q2 and in q3.
And I have even enabled mouse acceleration in Gnome.

But it's true that there's no movement with SDLGL if the mouse is moved
very slow.

[Anders Storsveen]

Anyway I have mouse acceleration in quake3 too, but I can't find any linux
support maillinglists/forums. Anyone know anything?

On Thu, 17 Mar 2005 12:49:51 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.
I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.
If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.
If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!
It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Hi,
I don't see such a behavior on my machine.
No matter how fast I move the mouse, the distance it covers is always
the same... in q2 and in q3.
And I have even enabled mouse acceleration in Gnome.
But it's true that there's no movement with SDLGL if the mouse is moved
very slow.

[Brendan Burns]

Its my experience (from fielding mouse problem reports from a lot of
different people) that mouse issues are often weird system level
interactions between X, the kernel and the graphics card. Lots of
different people running the same code see different mouse behavior.

One thing you might try is explicitly turning DGA of in your X server.
That may help (or try turning it on, if it is already off...)

<ot>
that last statement reminds me of a joke I heard recently:
Four engineers are in a car driving down the highway. The car stalls
and they stop it on the side of the road. The mechanical engineer
says, "its something with the engine, we've got to take it apart until
we find the problem." The chemical engineer says "no, its the gasoline
that's bad." The electrical engineer says "Its probably the battery."
And the computer engineer says, "I think if we get out and then get
back in it will work..."
</ot>

--brendan

Post by Anders Storsveen
Anyway I have mouse acceleration in quake3 too, but I can't find any
linux support maillinglists/forums. Anyone know anything?
On Thu, 17 Mar 2005 12:49:51 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.
I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.
If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.
If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!
It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Hi,
I don't see such a behavior on my machine.
No matter how fast I move the mouse, the distance it covers is always
the same... in q2 and in q3.
And I have even enabled mouse acceleration in Gnome.
But it's true that there's no movement with SDLGL if the mouse is moved
very slow.

--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2377 bytes
Desc: not available
URL: <http://icculus.org/pipermail/quake2/attachments/20050317/905ce202/attachment.bin>

[Anders Storsveen]

On Thu, 17 Mar 2005 12:49:51 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.
I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.
If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.
If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!
It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Hi,
I don't see such a behavior on my machine.
No matter how fast I move the mouse, the distance it covers is always
the same... in q2 and in q3.
And I have even enabled mouse acceleration in Gnome.
But it's true that there's no movement with SDLGL if the mouse is moved
very slow.

wel, that would seem that you have acceleration, only its constant at
higher speeds. Do you have the negative movement when moving really slow
with glx?

btw: I could make a demo for you guys to show what I mean.

[Anders Storsveen]

On Thu, 17 Mar 2005 12:49:51 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.
I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.
If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.
If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!
It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Hi,
I don't see such a behavior on my machine.
No matter how fast I move the mouse, the distance it covers is always
the same... in q2 and in q3.
And I have even enabled mouse acceleration in Gnome.
But it's true that there's no movement with SDLGL if the mouse is moved
very slow.

Well if it is no movment when moved very slow I would say that the
distance isn't the same.
If you move it that slow in glx and mark of a perimiter to move it in. and
then move it back really fast there should be a difference.

[Julien Langer]

Post by Anders Storsveen
Well if it is no movment when moved very slow I would say that the
distance isn't the same.
If you move it that slow in glx and mark of a perimiter to move it in. and
then move it back really fast there should be a difference.

Just tried it again. (in GLX mode)
Tried to move very slow and tried to move very fast. It's always the
same distance, so I really can't notice any mouse acceleration.

[Anders Storsveen]

well, does it move the opposite direction when moving it very slow? in glx?

On Thu, 17 Mar 2005 18:29:42 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
Well if it is no movment when moved very slow I would say that the
distance isn't the same.
If you move it that slow in glx and mark of a perimiter to move it in. and
then move it back really fast there should be a difference.

Just tried it again. (in GLX mode)
Tried to move very slow and tried to move very fast. It's always the
same distance, so I really can't notice any mouse acceleration.

[tei]

Highly erratic mouse beavior its often a incompatibility with Wine.

just kidding :D

Post by Anders Storsveen
well, does it move the opposite direction when moving it very slow? in glx?
On Thu, 17 Mar 2005 18:29:42 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
Well if it is no movment when moved very slow I would say that the
distance isn't the same.
If you move it that slow in glx and mark of a perimiter to move it
in. and
then move it back really fast there should be a difference.

Just tried it again. (in GLX mode)
Tried to move very slow and tried to move very fast. It's always the
same distance, so I really can't notice any mouse acceleration.

[Julien Langer]

Post by Anders Storsveen
well, does it move the opposite direction when moving it very slow? in glx?

nope it doesn't

However the mouse in GLX sometimes jumps a few pixels back, but that
also happens when moving the mouse very fast. I reported this bug
several times on this list but it hasn't been fixed yet.
But I think this bug is not what you are talking about.

[Anders Storsveen]

the mouse jumping back problem could be just mouse specific for you, does
it do the same in X? it could be that you move the mouse to fast for the
optics to keep up. but probably not, since you have reported it as a bug.

On Thu, 17 Mar 2005 23:18:52 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
well, does it move the opposite direction when moving it very slow? in glx?

nope it doesn't
However the mouse in GLX sometimes jumps a few pixels back, but that
also happens when moving the mouse very fast. I reported this bug
several times on this list but it hasn't been fixed yet.
But I think this bug is not what you are talking about.

[Anders Storsveen]

heres the demo, it actually didnt seem mouse acceleration was on in q2
now. but its still definantly on in q3...


On Thu, 17 Mar 2005 21:52:47 +0100, Anders Storsveen <wakko at generation.no>

Post by Anders Storsveen
On Thu, 17 Mar 2005 12:49:51 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.
I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.
If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.
If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!
It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Hi,
I don't see such a behavior on my machine.
No matter how fast I move the mouse, the distance it covers is always
the same... in q2 and in q3.
And I have even enabled mouse acceleration in Gnome.
But it's true that there's no movement with SDLGL if the mouse is moved
very slow.

wel, that would seem that you have acceleration, only its constant at
higher speeds. Do you have the negative movement when moving really slow
with glx?
btw: I could make a demo for you guys to show what I mean.

[Anders Storsveen]

bump, check out the demo.


On Fri, 18 Mar 2005 01:24:05 +0100, Anders Storsveen <wakko at generation.no>

Post by Anders Storsveen
heres the demo, it actually didnt seem mouse acceleration was on in q2
now. but its still definantly on in q3...
On Thu, 17 Mar 2005 21:52:47 +0100, Anders Storsveen
<wakko at generation.no>

Post by Anders Storsveen
On Thu, 17 Mar 2005 12:49:51 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.
I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.
If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.
If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!
It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Hi,
I don't see such a behavior on my machine.
No matter how fast I move the mouse, the distance it covers is always
the same... in q2 and in q3.
And I have even enabled mouse acceleration in Gnome.
But it's true that there's no movement with SDLGL if the mouse is moved
very slow.

wel, that would seem that you have acceleration, only its constant at
higher speeds. Do you have the negative movement when moving really slow
with glx?
btw: I could make a demo for you guys to show what I mean.

[Anders Storsveen]

anyone else got the negative movement bug that I have in glx?
anyone have any idea what it might be?

On Fri, 18 Mar 2005 23:53:55 +0100, Anders Storsveen <wakko at generation.no>

Post by Anders Storsveen
bump, check out the demo.
On Fri, 18 Mar 2005 01:24:05 +0100, Anders Storsveen

Post by Anders Storsveen
heres the demo, it actually didnt seem mouse acceleration was on in q2
now. but its still definantly on in q3...
On Thu, 17 Mar 2005 21:52:47 +0100, Anders Storsveen
<wakko at generation.no>

Post by Anders Storsveen
On Thu, 17 Mar 2005 12:49:51 +0100, Julien Langer <jlanger at zigweb.de>

Post by Julien Langer

Post by Anders Storsveen
I'm 100% sure that this problem is mouse accelleration related. I have
been whining about this for years now, linux
seems to have mouse accelleration that is impossible to turn off... It's
like this in every game! I've posting
around the net on this, and no one seems to figure it out.
I've done xset m 0 0 and set the mouseaccel to 1x in kde. but nothing
works.
If you try to move the mouse very slowly you will get the following
artifacts, in SDL you will get no or slow
movment, and in glx you will get negative movment and if you speed up a
little you will get zero movment and then
correct movment again. I'm definantly sure that this is some problem with
how X or some other backend handles mouse
and mouse accelleration. I'm also betting that, in regular x with mouse
acceleration set to "off" there is still
mouse acceleration, even though it is hard to detect.
If someone made an app that compared raw mouse input to the length
actually moved on the desktop I'm sure the
length would change dependant on the speed, even though the physical
length moved stays the same. But what I'm sure
of is that mouse acceleration in the game is what this problem is, it also
affects other games including quake3!
It's stupid to have to dualboot to windows to play games that are native
in linux and performes very well (and even
better in the case of q3) in linux when compared to windows.

Hi,
I don't see such a behavior on my machine.
No matter how fast I move the mouse, the distance it covers is always
the same... in q2 and in q3.
And I have even enabled mouse acceleration in Gnome.
But it's true that there's no movement with SDLGL if the mouse is moved
very slow.

wel, that would seem that you have acceleration, only its constant at
higher speeds. Do you have the negative movement when moving really slow
with glx?
btw: I could make a demo for you guys to show what I mean.