You are not logged in.
Hi,
for about a week now i have a very strange problem with the behavior of my mouse wheel in QuakeLive (and only in QL, works fine in browser etc). It simply isn't registering every "tick", feels like it's randomly dropping "ticks". It was working perfectly before, tho. An update of the QuakeLive client didn't happen in the relevant time-frame. Only did the occasional pacman -Syu.
What I tried to solve it up to now: Trying different mouses, testing mouse wheel behavior in other applications, testing in QuakeLive under Windows which works just fine.
Running Arch x86-64
€: Just took notice that the mouse wheel isn't working at all (even in a browser window f.e.) when the mouse is moving. So this isn't a QuakeLive problem. Updated the thread title to reflect this.
Last edited by jaysson (2012-03-25 19:52:42)
Offline
I have the same problem. It happens in Quake 1 engines too.
The mouse wheel only registers if there is no other mouse movement. I have to hold the mouse still, then I can use the wheel.
Glad to hear that I am not crazy and did not break something on my own.
Offline
Did this occur to you just recently? Or did it always behave like this for you?
€: Just confirmed it, mousewheel isn't working at all, even in a browser window etc, when the mouse is moving. So this isn't a QuakeLive problem.
Last edited by jaysson (2012-03-25 19:50:57)
Offline
Started some days ago so we might be able to nail down some package that does it. My desktop is shut down already for the night, I will check tomorrow.
I tried it in a random desktop window earlier, there I had no trouble. I only noticed it in QuakeLive and Quake 1.
Offline
Tried downgrading xf86-input-evdev and xorg-xinput in the meantime: no effect.
Last edited by jaysson (2012-03-25 21:44:52)
Offline
Hi,
I sent a little message to xorg about this:
http://lists.x.org/archives/xorg/2012-March/054338.html
add to it if you think it might help persuade them to look into it.
Don't seem to have any problem in browsers or elsewhere, just the games mentioned.
Offline
This bug has been driving me nuts over the past few weeks!
Took me until a few days ago to figure out what the problem was - moving the mouse + scroll wheel in games caused the issue.
Anyway, I've done some further troubleshooting, and this is what I've found (all are 64bit games):
game mode works
-----------------------------------------------------
assaultcube fullscreen has the bug
assaultcube windowed works fine
ioquake3 fullscreen has the bug
ioquake3 windowed has the bug
sauerbraten fullscreen has the bug
sauerbraten windowed works fine
urban-terror fullscreen has the bug
urban-terror windowed has the bug
xonotic-glx fullscreen works fine
xonotic-glx windowed works fine
xonotic-sdl fullscreen has the bug
xonotic-sdl windowed has the bug
assaultcube and sauerbraten are interesting cases, they suffer from the bug when fullscreen, but they work fine when windowed.
xonotic-glx works fine but xonotic-sdl does not.
I've tested sauerbraten and assaultcube full screen on the same computer with Ubuntu 11.10, and both games work fine (no bugs)
I've also tested assaultcube in Windows 8 consumer preview full screen and it also works fine (no bugs)
I've tested 3 different mice, logitech g9x, logitech g9, and a cheap generic mouse, there is no difference with regards to what mouse is used.
I've tested with gnome 3.2.1 both with and without fallback mode
I've tested this with on 2 different computers, 1 with an nvidia geforce 275 GTX, and the other with an nvidia geforce 8600 GT (both 64bit arch linux)
I've tested this with Linux kernel 3.3.0-1-ARCH as well as nvidia 295.33-2 from the arch-testing repositories
This bug does not effect desktop applications, like firefox and libreoffice
The relevant hardware I'm running is as follows:
nVidia GeForce GTX 275 (896MB), Intel core i7 975, 16GB RAM, 120GB SSD
The relevant software I'm running is as follows:
Linux kernel 3.2.13-1-ARCH x86_64, xorg-server 1.12.0-1, sdl 1.2.15-1, xf86-input-evdev 2.7.0-2, nVidia driver 295.33
I have a suspicion that SDL may contain the bug - as all the listed games (except xonotic-glx) use SDL - I'll do some more research and report back
Last edited by Rhubarb (2012-03-29 06:31:47)
Work smart, not hard.
Offline
I've performed some further minor testing, and I'm not sure which package is causing the bug now.
My laptop with an nVidia geforce 7400 GS running an old non-updated version of arch (last updated January 2012 sometime) and using the nouveau drivers - it does not present the bug when playing sauerbraten full-screen.
- It is using the same version of SDL (version 1.2.15-1), and Linux 3.2.5-1 (32bit x86)
Ubuntu 11.10 (which did not present the bug) was using SDL 1.2.14-6, and a really old nvidia driver version 173.14.30 - I tried to install the latest nvidia driver in Ubuntu 11.10, but failed to install it correctly.
My suspicions are that it could SDL 1.2.15-1 (x84_64 only), or nvidia 295.33, or something else (like xorg)
If someone could try reverting to older versions of nvidia / xorg and doing some tests that'd help in finding where the problem lies - then we could submit a bug report to them.
I'll keep trying a few more things here, and will report back if I find anything else.
Last edited by Rhubarb (2012-03-29 06:37:25)
Work smart, not hard.
Offline
All ioquake engine same problem/bug. Mouse wheel not responding while moving mouse ingame Urban Terror, OpenArena, Quake etc....
My problem i temporarily solved DOWNGRADE (xf86-input-evdev 2.6.0-4) and (xorg-server 1.11.4-1) and pacman ignoring upgrade .
warning: xf86-input-evdev: ignoring package upgrade (2.6.0-4 => 2.7.0-2)
warning: xorg-server: ignoring package upgrade (1.11.4-1 => 1.12.0-1)
But this solution is just a label (no solution), cannot be considered complete solution...
My GPU Nvidia 9500 GT 1GB Ram, Arch KDE / Gnome 3.2.13-1-ARCH 32 bit.
Last edited by valsin (2012-03-29 11:48:41)
Offline
Good job valsin, downgrading both packages worked for me, too. At least the packages at fault are specified now.
Offline
Same here: Last updates ( evdev-2.7.0-2 server-1.12.0-1 ) + Logitech G5 = wheel not working while moving mouse ( in urban terror )
a crappy fix:
export SDL_VIDEO_X11_DGAMOUSE=0
this will fix the mouse wheell issue. but, mouse speed is increased a lot when u switch betwen desktop and game window
Offline
Please report this bug, my ENG is very very very bad, i do not dare to report this bug, it would create chaos. txh...
EDIT ok i add task/bug hehe : https://bugs.archlinux.org/task/29191 cmon guys You also express.....
Last edited by valsin (2012-03-30 15:40:13)
Offline
This bug is still active and is still very harmful for playing 3D games in Linux here.
It's driving me crazy here.
I don't quite have the experience to help troubleshoot this bug, or communicate xorg logs.
I'm hoping that when the newer Linux Mint comes out (LM13?) that more people will be exposed to this bug and hence help to fix up this bug upstream.
And thanks valsin for helping to get the bug reports started off.
Work smart, not hard.
Offline
With the recent udev changes this is getting ugly now. After upgrading you have to update xorg-server and xf86-input-evdev or X wont start at all. Bug is still present.
So if you want to run your downgraded server and input versions, don't replace udev by systemd-tools.
Offline
Yep, I have some problems wiht xf86-input-evdev too. After upgrading xf86-input-evdev to 2.7.0-2 I had mouselook glitch in some 3D apps. Downgrading xf86-input-evdev to 2.6.0-4 solved the problem. However I had to downgrade my xorg-server and xorg-server-common to 1.11.4 because 1.12.0 refused to recognize my mouse and keyboard after X started with xf86-input-evdev - 2.6.0-4. So my upgrade list now looks like this:
initscripts-2012.05.1-3
kdelibs-4.8.3-2
systemd-tools-184-2
xf86-input-evdev-2.7.0-2
xorg-server-1.12.2-1
xorg-server-common-1.12.2-1
And to keep my system working as required I keep this packages not updated
Offline
Well I decided to risk and update my system on max. Well what can I say, everything works now
I presume the problem in my case was in xorg-server 1.12.0. Now with 1.12.2-1 everything works flawlessly. If there was a bug, they fixed it:)
Offline
Again there was a problem, and after the full upgrade, it is not solved.
Offline
There's a patch for this bug now, can be found at: http://cgit.freedesktop.org/xorg/xserve … 81bfe40f28
I'm guessing it'll be in the next version xorg-server or you can rebuild with the ABS.
Offline
So glad there's a fix, I was expecting the worst...
For anyone reading who wants to apply this fix, here's how I did it:
mkdir build
cd build
ABSROOT=. abs extra/xorg-server
cd extra/xorg-server
wget -O scrollfix.patch "http://cgit.freedesktop.org/xorg/xserver/patch/?id=2d4fda4b09e67e47d3e6fc4743fc6e81bfe40f28"
Now, I didn't bother modifying the PKGBUILD to include the patch as a source file. Here's what I did: edit the PKGBUILD; find the section where the other patches are applied; add the line `bash` directly after the last patch line; run makepkg; patch manually with patch -p1 when you are dropped into the shell; ctrl-D to continue makepkg.
The package will continue building. Then:
pacman -U xorg-server-1.12.2-1-x86_64.pkg.tar.xz xorg-server-common-1.12.2-1-x86_64.pkg.tar.xz
(replace filenames appropriately for the generated xorg-server and xorg-server-common packages)
And, of course, restart X.
Last edited by linkmaster03 (2012-06-26 21:25:43)
Offline
The patch from upstream has trickled down to the arch repos and has now fixed the problem for me.
$ pacman -Qi xorg-server
Name : xorg-server
Version : 1.12.3-1
URL : http://xorg.freedesktop.org
Licenses : custom
Groups : xorg
Provides : x-server
Depends On : libxdmcp libxfont udev libpciaccess libdrm pixman libgcrypt libxau xorg-server-common xf86-input-evdev
Optional Deps : None
Required By : nvidia-utils
Conflicts With : nvidia-utils<=290.10
Replaces : None
Installed Size : 3822.00 KiB
Packager : Andreas Radke <andyrtr@archlinux.org>
Architecture : x86_64
Build Date : Tue Jul 10 02:00:41 2012
Install Date : Tue Jul 10 13:08:22 2012
Install Reason : Explicitly installed
Install Script : No
Description : Xorg X server
I'm very happy now
Work smart, not hard.
Offline