You are not logged in.
A few weeks ago I got another hard drive, and with that I decided to redo my partitioning scheme to make up for the extra 250GBs I would have. Through the process I ended up installing Arch from scratch. There were no problems, that is, until I tried playing some games.
Right after the holidays I also purchased Enemy Territory: Quake Wars. I'd been playing the demo since the release and was pretty excited. The game worked (and still works) fine, but there was one thing I noticed: when using the sniper rifle or railgun, my mouse movement was slowed, and it would take a lot to switch from being zoomed in back to normal sight. Also related was the quickchat menu: when scrolling through the options with my mouse wheel it will freeze up and act erratically. Similarly, this also happens when my list of servers is updating from time to time.
Now, I've come to the conclusion that this can't be hardware related and that it isn't network related, either, the reasons being that the demo was working fine, my framerate is not dropping, and that my ping has been low. I also hesitate to call this "mouse lag" because it also makes the keyboard act funny while it's acting up. Trying to toggle the console or pressing esc, for instance, has no immediate effect.
At first I was under the impression that this was merely a problem with the retail version of the game, but after a little investigation I found out that the problem is also present in RTCW, and although I never play as a Covert Ops in Wolfenstein: ET, I'm assuming the problem would also appear in that. Specifically in RTCW it springs up when zoomed in with the Mouser, just as with ET:QW.
What might have changed after my system update? I know that I'm now using a newer version of Xorg, but I'm not sure this would affect it. My Nvidia version is the same as well, so what gives? What could have caused this strange issue?
Offline
Anyone?
Offline
I have the exact same problems. After the X.org upgrade I had to switch from evdev to the "mouse" driver for OpenGL games, and ever since I experience the same odd behaviour if I move the mouse too fast. Unfortunately I have not been able to fix this yet
Offline
I have the exact same problems. After the X.org upgrade I had to switch from evdev to the "mouse" driver for OpenGL games, and ever since I experience the same odd behaviour if I move the mouse too fast. Unfortunately I have not been able to fix this yet
then the two of u should downgrade to the last working xorg-server package and prove that does fix the issue and then write out a bug report.
Do you have usb mice? 64 bit system?
Last edited by jacko (2008-01-25 01:00:28)
Offline
Is there an "easy" way to do that? Keep in mind that since I reinstalled my pacman archives have also been cleared (unfortunately!). Does someone still any of the last "big" release packages laying around? This would be helpful.
Also, if I were simply to downgrade xorg-server, would this mess up anything dependency wise?
I'm using a USB mouse on a 32-bit system.
Offline
i had like some kind of the same problem, so i downgraded.
look here for details: http://wiki.archlinux.org/index.php/Downgrade_packages
i used this mirror: http://ftp.tu-chemnitz.de/pub/linux/sun … archlinux/
and downloaded this packages:
fglrx-8.40.4-1.pkg.tar.gz
fglrx-utils-8.40.4-1.pkg.tar.gz
fglrx-8.40.4-2-i686.pkg.tar.gz
xf86-video-vesa-1.3.0-1.pkg.tar.gz
xorg-server-1.2.0-5.pkg.tar.gz
xf86-input-mouse-1.2.1-1.pkg.tar.gz
kernel26-2.6.22.9-1-i686.pkg.tar.gz
xorg-xauth-1.0.1-1.pkg.tar.gz
xf86-input-evdev-1.1.5-1.pkg.tar.gz
xorg-xinit-1.0.4-1.pkg.tar.gz
xf86-input-keyboard-1.1.1-1.pkg.tar.gz
at first i removed the catalyst-stuff with "pacman -Rd", then downgraded the kernel (with "pacman -U <packagename>") and the other packages, rebooted, and now it's working fine for me again.
but don't ask me if it works with any newer version of those packages, or if downgrading every package i listed is really needed. i'm just happy that it's working again :)
(sry, ma english is not that good, but i hope u got the point :>)
Last edited by hst (2008-01-29 18:41:55)
:f
Offline
I had to use some different package versions and some of my files were different, but this worked; thanks for confirming it.
Smoon, if you still haven't worked this out, do what I did: go to the link hst posted, click on "testing," and then download old versions of all of the xorg and xf86 files you have installed on your system. You can find this out by going to your /var/cache/pacman/pkg directory and finding all of these packages. If your cache is empty the most important packages are probably xorg-server, xorg-xinit, xf86-input-mouse, and xf86-input-keyboard. What I did was find the "newest" 1.3 release of xorg-server, looked at the date, and downloaded the rest of the files with a matching date. For me it was September 8, I believe. I didn't need to downgrade my nvidia drivers or downgrade my kernel; things just worked!
Offline
So I tried removing all of the relevant packages from my IgnorePKG line, and it appears that this is still a problem. Considering the number of people that do play the ETs, I'm a bit surprised this annoyance hasn't made more noise. The only thing I can think to ask is:
Is anyone out there with up-to-date Xorg packages not seeing mouse lag in Enemy Territory? If so, please post so we can locate the cause of this, rather than just locking in at specific package releases.
...
Offline
Having this issue as well.
i686 on AMD64 with ATI9600mobility, Logitech MX510
using latest catalyst, xorg and stuff
Offline
same thing here... the mousewheel sometimes won't be recognized at all, but then also the next keyboard input is ignored. very weird.
got a razor diamondback, nvidia geforce 8800gt, intel e8400 ... tried from within kde as well as pure Xsession. also switching from windowed to fullscreen and back shows weird mouse issues.
Last edited by eNTi (2008-03-12 15:46:24)
Offline
Well, I guess we can confirm that it's not triggered by any particular hardware. I checked around the gentoo forums, and it looks like they had the same problem with no real resolution either. Although, I haven't actually tried any of them yet so one might accidentally work.
But someone did mention that it's a known Xorg bug, so hopefully it'll be resolved in some upcoming release.
...
Offline
i only experienced this after switching to using the evdev driver for my mouse
with the regular 'mouse' driver i didnt have any such problems...
Offline
I just checked out the evdev driver... holy crap that one is in a whole other class of screwy with ET. At least the mouse driver is consistently lagged behind, depending how many times you moved the wheel.
But here's my mouse entry; pretty standard really:
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mouse2"
Option "ZAxisMapping" "4 5"
EndSection
...
Offline
I have this problem too, with both drivers, "mouse" and "evdev". Any easy solution yet?
Offline
Edit: if this http://bbs.archlinux.org/viewtopic.php? … 28#p344128 fix doesn't work, try this:
Download this package: http://users.opengate.be/~glenn/arch/xo … pkg.tar.gz
and install it.
This package is the stock arch xorg-server but with this patch added: https://bugs.freedesktop.org/show_bug.cgi?id=13808
BIG FAT WARNING
This is "WORKS FOR ME" solution, and it may break ABI compatability!
Last edited by RedShift (2008-03-19 22:45:13)
:?
Offline
Sorry to say but the above solution isn't working for me.
Offline
Found a way to fix this; run this command before you start the game:
'export SDL_VIDEO_X11_DGAMOUSE=0'
Hope it will be fixed in future Xorg/evdev.
Offline
hst's post worked for me. I was having problems in Quake 3 Arena. I was able to best replicate the bug by using the gun in the game known as the lightning gun, since it constantly fires. If I clicked my mouse to fast, sometimes the gun wouldn't shoot. Upon letting go of the mouse, the gun would rapid fire, sometimes stopping by itself, or if I moved the mouse again. I also noticed sometimes trying to drop the console using the ~ key, it would sometimes take several seconds for it to work. Also many other strange problems, such as not being able to move for several seconds, or getting stuck walking in a certain direction. Great to see there is a solution, and I hope this is addressed at some time in the future.
Offline
Found a way to fix this; run this command before you start the game:
'export SDL_VIDEO_X11_DGAMOUSE=0'
Works for me. Thx.
Offline
kennae wrote:Found a way to fix this; run this command before you start the game:
'export SDL_VIDEO_X11_DGAMOUSE=0'Works for me. Thx.
for me too.
Offline
Does anyone know if this was fixed after the recent updates to some of the xf86 packages? Specifically the mouse/keyboard packages. I have 4 packages ignored to fix this problem, hoping I can unignore them soon.
:: Starting full system upgrade...
warning: xf86-input-keyboard: ignoring package upgrade (1.1.1-1 => 1.3.1-1)
warning: xf86-input-mouse: ignoring package upgrade (1.2.1-1 => 1.3.0-1)
warning: xorg-server: ignoring package upgrade (1.2.0-5 => 1.4.2-1)
warning: xorg-xinit: ignoring package upgrade (1.0.4-1 => 1.1.0-1)
Offline
Depends which problem you're having:
If slow mouse movements aren't being picked up, it seems that's been solved.
If using the wheel causes mouse movement events to be delayed, I tested that just recently and I still couldn't get it to work.
...
Offline
Depends which problem you're having:
If slow mouse movements aren't being picked up, it seems that's been solved.
If using the wheel causes mouse movement events to be delayed, I tested that just recently and I still couldn't get it to work.
Neither problem. Mine was that the mouse buttons/keyboard would lock sometimes until i moved the mouse... I'll just test and stop being lazy.
UPDATE: Still not fixed, whoop dee doo....
Last edited by justin (2008-07-09 19:37:11)
Offline
Alright, I came across this problem some time ago, and I finally found a forum talking about it.
I've been getting the delayed mouse movements when you scroll on almost all my games, Quake 1/2/3/4, Doom 1/2/3, Penumbra 1/2, ET:QW and anything else that uses SDL for an input layer. Even my own game I've been developing has this problem.
The thing is it'll only happen if I have SLi turned on.
Now I'm not using Archlinux, I'm on openSUSE 11.0, but considering it seems we are all experiencing the same problem I'd like to help.
I have 2x7600GT using the nvidia driver, I also have a Dual core AMD Athlon running on 64bit openSUSE Linux. I'm trying to figure out if there is a correlation between setups, so if you could post what your system is, we may be able to figure something out.
openSUSE 11.0
uname -a "Linux localhost 2.6.25.9-0.2-default #1 SMP PREEMPT Sun Jul 13 15:36:38 CDT 2008 x86_64 x86_64 x86_64 GNU/Linux"
2x7600GT using "nvidia" SLI set to "AFR"
Xorg version 1.4.0.90
Nvidia driver version 177.13
Offline
Hey, the problem finally disappeared on my system. Seems that the cause for it going away was switching from i686 to x86_64.
piko24, if you have any free space, test out Arch64. If it starts working over there as well, then it would be apparent that there's something going on in Arch64 that resolves the issue.
...
Offline