Ubuntu

sdl and evdev for mice does not work (xorg 1.4)

Reported by FrejSoya on 2008-02-07
70
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libsdl1.2 (Ubuntu)
Undecided
Unassigned

Bug Description

Run any SDL based game (like ioquake3). Make sure xorg uses evdev driver for input. This is default setup with hal based hotplug and xorg 1.4.
Mouse "flickers/resets" to the bottom right corner.
Changing driver back to "mouse" makes everything work.

Clearly going to annoy a lot of people if hardy ships with hal based hotplug since it defaults to evdev.

Yaroze (ricky-johansson) wrote :

Can be "solved" by doing export SDL_VIDEO_X11_DGAMOUSE=0 before you launch the game..
Works with ioquake3 anyway.

Julien Humbert (julroy67) wrote :

Should be to default, had it on my Gentoo too and you saved my life ;), I can play.

Alexander Blinne (sunday) wrote :

Had the same problem, SDL_VIDEO_X11_DGAMOUSE=0 worked. Thanks. Should really be default.

Stevie (stevie1) wrote :

same problem here. this should be really fixed!

Dmitriy Geels (dmig) on 2008-05-29
Changed in libsdl1.2:
status: New → Confirmed

other way is to add the following into xorg.conf:

Section "Module"
    SubSection "extmod"
        Option "omit xfree86-dga" # don't initialise the DGA extension
    EndSubSection
EndSection

however I still get crappier frames per second in a game compared to Gutsy, why?

Dmitriy Geels (dmig) wrote :

SDL_VIDEO_X11_DGAMOUSE=0 helps in UT2004, but doesn't help in: Penumbra Overture/Black Plague, Warsow, Secret Maryo Chronicles, so it is not a complete workaround

can someone confirm my other finding about frame rate drop?
example:

game enemy territory quake wars

* in Gutsy Gibbon start a map "Area22" on your computer deploy as GDF engineer, hop into Husky and drive around buildings in circles a few minutes. On my hardware I have not unlocked fps so it shows around 30FPS, fluctuates a bit (not totally stable)

* in Hardy Heron start the same map, and deploy as GDF engineer, drive around building with Husky again. On my hardware the game becomes impossible to play and FPS drops to "8"! (the key here is to drive constantly, not stopping the vehicle).

Dmitriy Geels (dmig) wrote :

klerfayt, FPS drop most likely caused by video driver or compiz. remember, that you have different versions of them in Gutsy and in Hardy

I installed the drivers manually and they are the same version, I don't use compiz either.
So nobody else has this fps issue? Games perform exactly same in both Gutsy and Hardy?

isecore (isecore) wrote :

Neither workaround solves the problem for me. Tried both doing the export and adding to my xorg.conf - no difference. Mouse is still jerky and erratic and moves to lower right-hand corner of the screen.

I'm running Hardy on x64, completely updated as of July 9th.

are you aware of patch submitted here?
https://bugs.freedesktop.org/show_bug.cgi?id=13808

how can I try it Intrepid for example? or I just have to wait for xorg version 1.5?

no change in Intrepid alpha3
I was hoping the patch here https://bugs.freedesktop.org/show_bug.cgi?id=13808 was going to be included in X.Org that should be version 1.5 (AFAIK) in Intrepid alpha3.

Why is it marked as libsdl bug?

Intrepid alpha4
X.Org version 1.5.0 RC 6
doing "xset m 1/8 1" in the console no longer exhibits problem described here (mouse cursor not moving while moving mouse itself slowly): https://bugs.freedesktop.org/show_bug.cgi?id=13808
but mouse problem in games stays same (mouse scroll wheel mix up with other keys, lower fps).
I'm lost at this point cause I got the understanding that the bug is same then reading this forum topic:
http://bbs.archlinux.org/viewtopic.php?pid=344128

The performance loss appears to be specific for only one game I have - "Enemy Territory: Quake Wars". I can't reproduce it in "Warsow" or "Wolfenstein: Enemy Territory". So this must be completely different bug, unrelated to messed up mouse wheel.

benchmarks were done with identical nvidia drivers (173.14.12) and xorg.conf

etqw:
kubuntu710: 51.2 51.4 51.6
kubuntu8041: 45.3 45.3 45.6 (if I actually attempt to play the game, the fps is much worse = 8)

warsow
kubuntu8041: 194.4 194.2 194.1
kubuntu710: 195.4 195.4 195.3

enemy territory
kubuntu710: 147.0 147.1 146.8
kubuntu8041: 151.2 151.0 151.6

I have positive news!
please confirm my findings on (k)ubuntu hardy heron:

sudo rmmod usbhid
sudo modprobe usbhid mousepoll=2

these two commands fix the mousewheel issues entirely in the following games: "wolfenstein: enemy territory", "warsow", "enemy territory: quake wars", "doom3 demo"

OOPS!
This has nothing to do with rmmoding usbhid and then modprobeing it back.
The problem seems to have fixed itself somehow for me (kubuntu 8.10).
I don't know if it's because of recent updates or software I've installed recently. I'll promise to investigate this further with clean install of kubuntu 8.10 and see if the fix for mousewheel appears to be happening with particular package(s) installed.

The previous comment contains errors - then I said kubuntu 8.10 - I meant kubuntu 8.04.1 (hardy heron). Sorry.

 Ok. I'm not going to do clean install of kubuntu hardy heron (8.04) since the mouse wheel problem is back. Fortunately I found out how it fixed itself - I've to plug in USB Logitech RumblePad 2 joystick, reboot laptop and unplug the joystick (remove the joystick) as soon as I see the BIOS screen. This way the mousewheel acts normally in kubuntu 8.04 until the odd behavior comes back after some time, certain actions(?).

In short:
plug in joystick
reboot kubuntu 8.04
unplug the joystick then I see BIOS screen
mouse works ok until some action(s) returns the odd behavior (I'm not sure at this point what resets bug)
repeat the cycle

- this has no effect for kubuntu 8.10 intrepid; also mouse works fine without any tricks in kubuntu 7.10 gutsy

Vadim Peretokin (vperetokin) wrote :

Having this issue also, but I am not using evdev.

using the dga fix works on cube 2 but not on quake wars

Siegfried Gevatter (rainct) wrote :

I can confirm that tremulous is nearly unusable on Intrepid (the mouse moves painfully slow and it's hard to get it where you want it) and that running it like "SDL_VIDEO_X11_DGAMOUSE=0 tremulous" fixes it.

yossarian_uk (morgancoxuk) wrote :

Hi

I have been having the exact same issues with wt / etqw, etc

This is how I fixed it

- open console in game

in_dgamouse 0

- this makes my mouse freeze - i have to quit (using the game console)

As the command freezes my mouse I have to restart X
(You only have to do this the once)

- restart game
- its completely fixed !!!!!!!!

you could always edit the .cfg file and manually edit in_dgamouse setting

this fixes et - etqw and doom3 .......

Not sure why it freezes the 1st time in in_dgamouse=0 mode (I am runnig ubuntu and arch - the same issue as you was effcting both distros btw)

see http://corent.proboards42.com/index.cgi?board=bugsolved&action=print&thread=156 for more

Mousewheel lags are gone in Ubuntu 9.04 Jaunty Jackalope, games tested: "Wolfenstein: Enemy Territory" and "Warsow".

yossarian_uk (morgancoxuk) wrote :

Not had the issue at all since 9.04 (or in Arch Linux any more) - 9.10 also is fine, looks like the SDL mouse issue is now fised.

Was a really odd bug!

Changed in libsdl1.2 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.