| Summary: | SDL Games on Logitech G5 results in uncontrolable mouse | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Pavol Rusnak <stick> |
| Component: | events | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED WORKSFORME | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | CC: | bombasticbryan, espen_g, slouken |
| Version: | 1.2.13 | Keywords: | target-1.2.14 |
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | https://bugzilla.novell.com/show_bug.cgi?id=419893 | ||
| Attachments: |
Hardware setup and xorg.conf from Espen
Xorg.0.log for Ubuntu 9.0.4 on Mac Pro 2009 |
||
|
Description
Pavol Rusnak
2008-08-25 07:52:23 UTC
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. (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. 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. 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. Created attachment 372 [details]
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.
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.) Ryan, I'm leaving you this one too; it might be related to bug 609 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. Created attachment 379 [details]
Xorg.0.log for Ubuntu 9.0.4 on Mac Pro 2009
I just tried Padman and it worked fine... 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! 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. 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. |