Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL Games on Logitech G5 results in uncontrolable mouse #425

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

SDL Games on Logitech G5 results in uncontrolable mouse #425

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Labels
worksforme We can't reproduce the bug

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 10, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 1.2.13
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2008-08-25 07:52:23 +0000, Pavol Rusnak wrote:

Sax's config of a G5 mouse results in a uncontrollable floating mouse cursor on
games that utilize SDL. I notice it also configures 2 mouse entries as well.
Games like Padman once launched results in not being able to even select
menu's. Using the plain old mouse driver works for some games. Other games result in the same behavior. An example of a game that still exhibits the issue is Soldier of Fortune.

Here is the xorg that sax generates with a G5.


/.../

SaX generated X11 config file

Created on: 2008-08-24T10:44:55-0600.

Version: 8.1

Contact: Marcus Schaefer sax@suse.de, 2005

Contact: SaX-User list https://lists.berlios.de/mailman/listinfo/sax-users

Automatically generated by [ISaX] (8.1)

PLEASE DO NOT EDIT THIS FILE!

Section "Files"
FontPath "/usr/share/fonts/misc:unscaled"
FontPath "/usr/share/fonts/local"
FontPath "/usr/share/fonts/75dpi:unscaled"
FontPath "/usr/share/fonts/100dpi:unscaled"
FontPath "/usr/share/fonts/Type1"
FontPath "/usr/share/fonts/URW"
FontPath "/usr/share/fonts/Speedo"
FontPath "/usr/share/fonts/PEX"
FontPath "/usr/share/fonts/cyrillic"
FontPath "/usr/share/fonts/latin2/misc:unscaled"
FontPath "/usr/share/fonts/latin2/75dpi:unscaled"
FontPath "/usr/share/fonts/latin2/100dpi:unscaled"
FontPath "/usr/share/fonts/latin2/Type1"
FontPath "/usr/share/fonts/latin7/75dpi:unscaled"
FontPath "/usr/share/fonts/baekmuk:unscaled"
FontPath "/usr/share/fonts/japanese:unscaled"
FontPath "/usr/share/fonts/kwintv"
FontPath "/usr/share/fonts/truetype"
FontPath "/usr/share/fonts/uni:unscaled"
FontPath "/usr/share/fonts/CID"
FontPath "/usr/share/fonts/ucs/misc:unscaled"
FontPath "/usr/share/fonts/ucs/75dpi:unscaled"
FontPath "/usr/share/fonts/ucs/100dpi:unscaled"
FontPath "/usr/share/fonts/hellas/misc:unscaled"
FontPath "/usr/share/fonts/hellas/75dpi:unscaled"
FontPath "/usr/share/fonts/hellas/100dpi:unscaled"
FontPath "/usr/share/fonts/hellas/Type1"
FontPath "/usr/share/fonts/misc/sgi:unscaled"
FontPath "/usr/share/fonts/xtest"
FontPath "/opt/kde3/share/fonts"
InputDevices "/dev/gpmdata"
InputDevices "/dev/input/mice"
EndSection

Section "ServerFlags"
Option "AllowMouseOpenFail" "on"
Option "ZapWarning" "on"
EndSection

Section "Module"
Load "dbe"
Load "type1"
Load "freetype"
Load "extmod"
Load "glx"
EndSection

Section "InputDevice"
Driver "kbd"
Identifier "Keyboard[0]"
Option "Protocol" "Standard"
Option "XkbLayout" "us"
Option "XkbModel" "microsoftpro"
Option "XkbRules" "xfree86"
EndSection

Section "InputDevice"
Driver "evdev"
Identifier "Mouse[1]"
Option "InputFashion" "Mouse"
Option "Name" "Logitech Gaming Mouse"
Option "Pass" "3"
Option "Vendor" "Sysp"
Option "evBits" "+1-2"
Option "keyBits" "~272-287"
Option "relBits" "~0-2 ~6 ~8"
EndSection

Section "InputDevice"
Driver "mouse"
Identifier "Mouse[3]"
Option "Buttons" "5"
Option "Device" "/dev/input/mice"
Option "Name" "ImPS/2 Generic Wheel Mouse"
Option "Protocol" "explorerps/2"
Option "Vendor" "Sysp"
Option "ZAxisMapping" "4 5"
EndSection

Section "Monitor"
Option "CalcAlgorithm" "XServerPool"
DisplaySize 380 290
HorizSync 31-75
Identifier "Monitor[0]"
ModelName "1600X1200@60HZ"
Option "DPMS"
Option "PreferredMode" "1600x1200"
VendorName "--> VESA"
VertRefresh 50-60
UseModes "Modes[0]"
EndSection

Section "Modes"
Identifier "Modes[0]"
EndSection

Section "Screen"
DefaultDepth 24
SubSection "Display"
Depth 15
Modes "1600x1200" "1600x1024" "1600x1000" "1400x1050" "1280x1024"
"1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720"
"1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"
EndSubSection
SubSection "Display"
Depth 16
Modes "1600x1200" "1600x1024" "1600x1000" "1400x1050" "1280x1024"
"1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720"
"1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"
EndSubSection
SubSection "Display"
Depth 24
Modes "1600x1200" "1600x1024" "1600x1000" "1400x1050" "1280x1024"
"1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720"
"1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"
EndSubSection
SubSection "Display"
Depth 8
Modes "1600x1200" "1600x1024" "1600x1000" "1400x1050" "1280x1024"
"1440x900" "1280x960" "1366x768" "1280x800" "1152x864" "1280x768" "1280x720"
"1024x768" "1280x600" "1024x600" "800x600" "768x576" "640x480"
EndSubSection
Device "Device[0]"
Identifier "Screen[0]"
Monitor "Monitor[0]"
EndSection

Section "Device"
BoardName "GeForce 8800 GT"
BusID "4:0:0"
Driver "nvidia"
Identifier "Device[0]"
VendorName "NVIDIA"
EndSection

Section "ServerLayout"
Identifier "Layout[all]"
InputDevice "Keyboard[0]" "CoreKeyboard"
InputDevice "Mouse[1]" "CorePointer"
InputDevice "Mouse[3]" "SendCoreEvents"
Option "Clone" "off"
Option "Xinerama" "off"
Screen "Screen[0]"
EndSection

Section "DRI"
Group "video"
Mode 0660
EndSection

Section "Extensions"
Option "Composite" "on"
EndSection

On 2008-10-29 03:30:47 +0000, Espen Grønvold wrote:

Sounds similar to my problems with a Logitech VX Nano mouse also using evdev, it seeks towards the lower right corner (highest x, y value). It's motions are triggered by the incoming events. At slow movement speeds the mouse works as expected. At medium speed it seems to be moving choppy and seeking towards the corner. At high speed (or large change) the mouse stays in the corner and will not move from it.

It seems to me like there is a threshold that if you move further than a certain distance in either or both x and y direction between two consecutive events, the mouse will jump towards a higher x or y coordinate.

Said in another way, if a mouse move event gives a larger relative change than a given value(unknown atm), there will be added another value (also unknown atm) added to the relative movement, so the axis changed will have a jump in value to a higher value.

This might be some sort of sign error maybe, but I shouldn't assume too much without having read the code.

On 2008-10-29 03:53:17 +0000, Espen Grønvold wrote:

(In reply to comment # 1)
After further investigation, you may disregard most of the last post, it is unrelated to the amount of movement. It still is related to the mouse movement events, the mouse pointer will not move anywhere unless the mouse hardware is moved.

Further investigation seems to suggest that the problem is related to timing, and that the first mouse event to occur after a certain time, (about a second for me) is receiving a constant increase to the X axis and about twice the same amount to the Y axis.

On 2008-11-09 01:45:54 +0000, Espen Grønvold wrote:

this is definitely linked to the "evdev" running three mice simultaneously, only the "evdev" device has problems.

It seems that the mouse event is adding some value to the x and y axis, so for the "evdev" device it is reporting the wrong relative and absolute movement.

On 2009-09-23 20:26:06 +0000, Sam Lantinga wrote:

Espen, can you give me more information about your hardware configuration and your X11 config file?

Does the issue happen with the test programs in the latest SDL snapshot?
http://www.libsdl.org/tmp/SDL-1.2.zip

Try out test/testwm and watch the event output. You can use Ctrl-G to toggle binding the mouse to the window. You can click the mouse button to hide the mouse. Grabbed and hidden mouse should switch it to relative motion mode.

On 2009-09-24 07:16:23 +0000, Espen Grønvold wrote:

Created attachment 372
Hardware setup and xorg.conf from Espen

This is the output of lshw, lsusb and my current xorg.conf as of 20090924. Submitted as additional documentation.

On 2009-09-24 08:07:21 +0000, Espen Grønvold wrote:

I have tested the applications, as well as DosBox 0.72 and an application I've made myself, and it seems that the problem still exists when the mouse cursor is hidden (relative mode?)

The test/testwm application worked as expected.
DosBox has a problem with the mouse cursor (in Dune2 this time) seeking towards the lower right corner, regardless of fullscreen or not. Recompiling made no difference.
My own application worked as expected when the mouse cursor was visible, but went crazy when the mouse cursor was not visible. (Mono C# with SDL.net, I'll recompile SDL.net to see if it changes.)

On 2009-09-27 23:51:18 +0000, Sam Lantinga wrote:

Ryan, I'm leaving you this one too; it might be related to bug 609

On 2009-09-29 21:34:26 +0000, Sam Lantinga wrote:

Oh hey, I just noticed, I happen to be using a G5 mouse right now!

I'm not having any problems, and I'll attach my Xorg.0.log for comparison.

On 2009-09-29 21:35:52 +0000, Sam Lantinga wrote:

Created attachment 379
Xorg.0.log for Ubuntu 9.0.4 on Mac Pro 2009

On 2009-09-30 00:24:38 +0000, Sam Lantinga wrote:

I just tried Padman and it worked fine...

On 2009-10-01 02:02:20 +0000, Sam Lantinga wrote:

I just did a fresh install of Fedora 9 i386 with no updates and built hhexen
using the latest SDL 1.2 snapshot and it worked perfectly for me... well except
for enabling the DGA mouse tweaking the color palette, but I think that's an X
server bug.

At this point, the only thing I can think of to do is have someone who's seeing
this problem do two things:

  1. Print out the values for the mouse events you're getting from SDL
  2. Upgrade your X server to XOrg 1.6 or newer

Thanks!

On 2009-10-10 22:52:40 +0000, Ryan C. Gordon wrote:

I'm honestly thinking this is a bug in x.org that has since been
fixed...upgrading to the latest of your favorite distro will probably make it go away.

If we can't make some progress on this bug in the next few days, we're probably
going to finish 1.2.14 without this and close the bug as WORKSFORME. I can't
think of anything else we can do here, unfortunately.

(Adding target-1.2.14 keyword, so we know to revisit before we wrap up 1.2.14.)

--ryan.

On 2009-10-17 10:59:36 +0000, Sam Lantinga wrote:

This appears to be a bug in X.org that has been fixed in the latest release. Please re-open this bug if you can reproduce it in the latest X.org release.

@SDLBugzilla SDLBugzilla added bug worksforme We can't reproduce the bug labels Feb 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
worksforme We can't reproduce the bug
Projects
None yet
Development

No branches or pull requests

1 participant