Mouse weirdness, evdev, opengl, xorg

Message

scrooge · Post by **scrooge** » Fri Sep 28, 2007 2:02 pm

Not sure if this is the right place to post but after updating to newest Xorg my mouse (MX500) has been acting very strangely. Everything works fine at desktop though and I didn't make any changes to my xorg.conf after/before update.

I noticed something was wrong when I went to play Enemy Territory (launched via XQF). The mouse didn't react to slow movements but faster movement was ok. This was both in menus and in-game.

Then I launched the game normally. Once it got into menus, the mouse/cursor was "lagging", doing something else than what I did. Also mouse clicks would register 5-10 seconds later (that is if I was able to hit any boxes). It was totally unusable.

Weirdest part is that the mouse works perfectly normal if I have Kaffeine or Audacious running in the background.

I use evdev in xorg.conf and tested with mouse driver. The mouse driver works without a problem, although the sidebuttons wont work in ET for some reason. Tried different configuration options and even deleted the whole InputDevice part but it didn't help either.

I have Nvidia ti4200 with 96.39 drivers and have to start X with -ignoreABI. Could that be the reason somehow? Strange evdev/opengl/xorg bug? Same thing happens on Quake3 demo btw.

Code: Select all

Section "InputDevice"
        Identifier  "MX500"
        Driver      "evdev"
        Option      "Name" "B16_b_02 USB-PS/2 Optical Mouse"
        Option      "Buttons" "10"
        Option      "ZAxisMapping" "4 5 6 7"
 EndSection

tngram · Post by **tngram** » Fri Sep 28, 2007 2:35 pm

Hi,

Try the following to identify the mouse with these option:

Option "product" "0xc025"
Option "vendor" "0x046d"

Instead of Option "Name" "B16_b_02 USB-PS/2 Optical Mouse".

That's what I use with my MX500 and a ATI Radeon9000 and I play ET without any problem.

Hope it helps.

scrooge · Post by **scrooge** » Fri Sep 28, 2007 2:41 pm

Nope, didn't help. Everything worked fine before xorg update. I've rebuilt the xf86-input drivers too.

fatcat.00 · Post by **fatcat.00** » Sun Sep 30, 2007 3:37 pm

I have the exact same problem! Started after I moved up to xorg 1.4 too. Enemy Territory too

Code: Select all

Section "InputDevice"
        Identifier "USBMouse"
        Driver  "mouse"
        Option  "Protocol"      "auto"
        Option  "Device"        "/dev/input/mice"
        Option  "ZAxisMapping"  "4 5"
        Option  "Emulate3Buttons"       "no"
        Option  "Resolution"    "1200"
EndSection

Today is the first day I've had to try to fix it, will post back with any solution should I find one.

VoVaN · Post by **VoVaN** » Mon Oct 01, 2007 2:52 pm

I've the same problem, back to the old xorg at the moment. This problem mentioned by few persons as well in the general topic concerning new Xorg (http://forums.gentoo.org/viewtopic-t-57 ... ight-.html).

Aphax · Post by **Aphax** » Tue Oct 02, 2007 4:46 am

Just to confirm, I've encountered the exact same issues you described for Enemy Territory with the Darwinia demo the other day, also running Xorg 7.3 with an MX500 using the evdev driver (mouse resolution tweaked with locomo). On the other hand, I had no problems in World of Warcraft running under Wine. On top of the Darwinia issues I have also been getting some subtle but odd mouse misbehaviours in Gnome (2.18). Before Xorg 7.3, in Gnome's mouse settings applet (gnome-mouse-properties) I was able to disable mouse acceleration and adjust my mouse's sensitivity by setting the Sensitivity slider all the way to the left, and then using the Acceleration slider to basically set the sensitivity, which I realise is kind of odd, but for some reason that's how it worked for me. Now that I've upgraded to Xorg 7.3, there doesn't seem to be a straight forward way to disable acceleration or adjust my sensitivity, it seems to work best if I leave both sliders somewhere in the middle. If I don't, I get either normal accelerated mouse movement (which I dislike), or I get *inverse* acceleration, i.e. the faster I move the mouse, the slower it goes...

I forgot about this for a while until today when I changed my mouse to a Razor/Microsoft Habu and although I have no issues in Darwinia anymore (though I did switch to the 'mouse' driver instead of evdev, not sure if it maybe has to do with that, will have to try later), I'm still suffering from the strange mouse behaviour in Gnome. I've spent the entire evening trying to track down what is happening, but so far I've been able to rule out any change in Gnome's mouse settings applet causing this (in fact, the code responsible for setting these with X hasn't been touched for a long time). I suspect new Xorg mouse acceleration code to be responsible for this, see http://lists.freedesktop.org/archives/x ... 18643.html (I'm guessing this code went into 7.3, but I'm not even sure of that). As for the Darwinia/ET issues, maybe it's some weird interaction between SDL (Does ET actually use SDL?) and the new Xorg (and maybe in combination with an MX500 too? Since I'm not getting this anymore).

I have at least been able to definitely disable mouse acceleration by running 'xset m 0 0'.

Aphax · Post by **Aphax** » Thu Oct 04, 2007 9:21 am

Looks like this is an issue with evdev, just changed my config back to evdev and the problem has returned. It's really weird, it is as if there is a delay in processing input events, however it only processes anything at all if I keep the mouse moving, so if I hold it still for a while, nothing happens, and if I move it again it starts processing old events, so it gets really weird.

VoVaN · Post by **VoVaN** » Thu Oct 04, 2007 11:15 am

Aphax wrote:Looks like this is an issue with evdev, just changed my config back to evdev and the problem has returned. It's really weird, it is as if there is a delay in processing input events, however it only processes anything at all if I keep the mouse moving, so if I hold it still for a while, nothing happens, and if I move it again it starts processing old events, so it gets really weird.

I have this problem with both evdev and mouse driver!

fatcat.00 · Post by **fatcat.00** » Thu Oct 04, 2007 3:20 pm

Yes mine is with the mouse driver...haven't tried evdev.

c0nv1ct · Post by **c0nv1ct** » Sat Oct 06, 2007 8:02 pm

Same problem here, just noticed it today trying to play ET, tested with Quake3/4 and UT2004, all the same.

My problem is slightly different, if i move the mouse in a straight vertical or horizontal line at a moderate speed, its fine, but if i move fast or in a circular motion, the mouse lags badly. If i lag it enough it will mess up the mouse input entirely, causing it to go in random directions. Even keyboard causes slight mouse movement when it goes all crazy like that.

nVidia 7800GT using 100.14.19 drivers
Xorg is 7.3, using evdev driver with my Logitech G5

Aphax · Post by **Aphax** » Mon Oct 08, 2007 7:10 am

c0nv1ct wrote:Same problem here, just noticed it today trying to play ET, tested with Quake3/4 and UT2004, all the same.

My problem is slightly different, if i move the mouse in a straight vertical or horizontal line at a moderate speed, its fine, but if i move fast or in a circular motion, the mouse lags badly. If i lag it enough it will mess up the mouse input entirely, causing it to go in random directions. Even keyboard causes slight mouse movement when it goes all crazy like that.

nVidia 7800GT using 100.14.19 drivers
Xorg is 7.3, using evdev driver with my Logitech G5

Yeah that is sort off what I was getting as well, I had trouble explaining it. I don't know why this problem goes away when I switch to the mouse driver while it doesn't for others, what happens for you if you switch to "mouse" instead of evdev?

Devport · Post by **Devport** » Mon Oct 08, 2007 7:29 am

I have this problem, too. For me it occured using the mouse driver and persisted when I switched to evdev. It seems to me that the new server / drivers confuse mouse and keyboard input devices under certain circumstances.

grumble · Post by **grumble** » Thu Oct 11, 2007 4:58 pm

OK I am the next one who has the problem- either with evdev and also with mouse driver.
I use following packets:
xorg-x11 7.3
x11-base/xorg-server 1.4-r2
x11-drivers/xf86-input-evdev 1.1.5-r2
x11-drivers/xf86-input-mouse 1.2.2-r1

and et-2.60 (enemy territory 2.60b), quake3 and ut2004 ...
I have a Logitech MX300 mouse

Sometimes the problem is not there -
but most times its like described above... when I move the mouse to fast - it seams
like the buffer gets full and it takes nearly 20 seconds for my PC to do the mouse moves
I did in 3 seconds... looks like a buffer problem to me...

Can someone please find a solution ASAP - as I am watching this thread now for nearly 2 weeks
and its really boring- because I had to start XP to play and I dont want to do that

Cheers

tngram · Post by **tngram** » Fri Oct 12, 2007 10:34 am

Well that sure is weird.

Because i have one laptop with MX500 and a desktop with a MX518, both have the latest stable release of evdev, xorg-server, XQF, Enemy Territory and RTCW and everything runs just fine.

Please give another try regarding how to identify the mouse (see my above post for MX500).

Tomorrow i'll post my full InputDevice section for both the MX500 and MX518 to see if we can solve this.

scrooge · Post by **scrooge** » Fri Oct 12, 2007 3:04 pm

I haven't found a reason or solution. It isn't a big problem anymore, I just keep Audacious opened on the background while I play and everything is fine.

eae · Post by **eae** » Fri Oct 12, 2007 8:41 pm

I have the same problem (tried with enemy territory and warsow), but only if I start the game in another xorg server. If I start it in the same server as kde, it seems to work properly, except that the left shift key seems to randomly stop working (which is all-important to me since it's my attack key

).
I think I'm going to downgrade xorg.

Just to be sure, what should I do to correctly downgrade xorg? I.E. what packages do I have to re-emerge, and to which version?

Aphax · Post by **Aphax** » Sat Oct 13, 2007 12:58 pm

scrooge wrote:I haven't found a reason or solution. It isn't a big problem anymore, I just keep Audacious opened on the background while I play and everything is fine.

Same here, running audacious makes it go away, I don't even have to have it play music, just need it started up. Sadly Audacious also has an impact on my FPS in some of the heavier games so it's not a perfect workaround for me.

gregf · Post by **gregf** » Sun Oct 14, 2007 5:40 am

Just came across this topic. I was using evdev and anytime I would run a game I would get bad lag with my mouse, to the point where it was almost unusable. I got tired of this and tried to go back to the normal xorg mouse drive and that solved it. Anyone find a solution to the evdev problem though?

VValdo · Post by **VValdo** » Sun Oct 21, 2007 5:36 am

Anyone come up with a solution to this?

VValdo · Post by **VValdo** » Sun Oct 21, 2007 5:57 am

Also, I notice that if I use ^G to "free" the cursor in ut2004 I get full response again. By toggling back and forth it seems to work sometimes in-game.

W

psofa · Post by **psofa** » Thu Oct 25, 2007 3:08 pm

*bump*
This issue is really annoying

VValdo · Post by **VValdo** » Sat Oct 27, 2007 7:25 am

Saw a thread that discusses somethng similar... anyone try

export SDL_VIDEO_X11_DGAMOUSE=0

and see if it makes a difference (running the game in the same shell you do the above)

also.. are you guys running synergys?

W

fatcat.00 · Post by **fatcat.00** » Sun Nov 11, 2007 5:41 pm

I just tried the "export SDL_VIDEO_X11_DGAMOUSE=0" suggestion, no difference for me. Also tried running Audacious, no improvement either.

Aphax · Post by **Aphax** » Mon Dec 24, 2007 12:18 am

Switched to a Microsoft Habu (

) mouse now, and the problem is still there. I also notice it with the normal mouse driver now, though to a much lesser degree than with evdev.

Jinxter2K7 · Post by **Jinxter2K7** » Mon Dec 24, 2007 1:21 am

scrooge wrote: Everything worked fine before xorg update. I've rebuilt the xf86-input drivers too.

Go back to Xorg 7.2 until 7.3 is fixed. I had the same problem and that was the only solution I could find.