doom3 and xserver-xorg-input-evdev

[berarma]

Hi.

I've installed a new Logitech G5 mouse with the xorg "mouse" driver and I couldn't use the horizontal wheel, but everything else was working ok. I've changed to the "evdev" driver and now almost everything is well since I can use all the mouse buttons and wheels with applications.

I've discovered that the "evdev" driver requires disabling the DGA extension for most games. But I have some additional issues with Doom3 as it ignores slow mouse movements while working for fast mouse movements resulting in important jerkyness. It worked well before with the same mouse and the "mouse" driver.

I've used "export SDL_VIDEO_X11_DGAMOUSE=0" and added this to xorg.conf module section:
SubSection "extmod"
Option "omit xfree86-dga" # don't initialise the DGA extension
EndSubSection

For doom3, I've played with combinations of "in_dgamouse" and "in_mouse" with no luck. Above behaviour was checked with "in_dgamouse 0" and "in_mouse 1" (also 2 and 3).

Any idea why is this happenning? Possible solutions? Could it be possible having two devices configured with different drivers but the same mouse?

Thanks for reading.

[brebs]

ignores slow mouse movements

See thread re xset bug.

[berarma]

Thank you very much, now I know I have to wait for this bug to be fixed or downgrade. Sorry, I've come back late since I haven't had time to play lately.

[epoch]

Quick edit: This isn't just Doom 3. This effects any id tech 3 engine game, including enemy territory, as well as tech 4 games, but that is limited to Doom 3. Quake 4 and Prey work fine. However, it does not effect later, open-source-q3-based games such as Nexuiz or OpenArena.

Likewise, it doesn't effect Enemy Territory: Quake Wars, although that is a Tech 4 game. I have yet to determine the underlying reason as to why some games work and others do not. I think it's related to something called "raw input" mouse in the games.

Thank you very much, now I know I have to wait for this bug to be fixed or downgrade. Sorry, I've come back late since I haven't had time to play lately.

According to the link you gave, that particular sensitivity bug has been corrected at the end of June in Xorg.

1) I don't know if that bug (13808 of Xorg) is truly the reason behind this issue.
2) I don't know if the fix for that bug has made it into Debian (sid or otherwise) as the versioning schemes between Debian and Xorg are a little screwy.
3) The open debian bug, for reference is 450851 and is still open.

I am going to attempt to downgrade the evdev_drv.so lib, dated Nov 2006, (md5: 5326422c9258c1583d577e6b0dbfd3fd) to see if that corrects the issue, as indicated by message #50 in the BTS thread and will report back tonight.

Current (bugged) version, for the sake of others looking at this later, from my Xorg logs:

Code: Select all

(II) LoadModule: "evdev"
(II) Loading /usr/lib/xorg/modules/input//evdev_drv.so
(II) Module evdev: vendor="X.Org Foundation"
  compiled for 1.4.0, module version = 1.2.0
  Module class: X.Org XInput Driver
  ABI class: X.Org XInput driver, version 2.0


[epoch]

Downgrading doesn't fix it.