Joystick causes mouse cursor to drift to upper left of screen

Replaced PS/2 mouse with USB mouse and problem occurred while running jscal.

Thanks trespasser, that solved my question.

Glad to help, mate.

Surely this is bug, right???

I recently switched to Ubuntu 10.10 from Mandriva and now have you same problem. However, I am using a Saitek yoke for X-plane and it now seems to behave like my USB mouse. The mouse goes to the left of the screen but that it because it is responding to the throttle lever which is usually left at one extreme.

I tried trespasser's suggestion:

darrell@beeker:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ USB Optical Mouse id=8 [slave pointer (2)]
⎜ ↳ Logitech Logitech USB Keyboard id=10 [slave pointer (2)]
⎜ ↳ Saitek Saitek Pro Flight Yoke id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Power Button id=7 [slave keyboard (3)]
    ↳ Logitech Logitech USB Keyboard id=9 [slave keyboard (3)]
    ↳ Saitek Saitek Pro Flight Yoke (keys) id=12 [slave keyboard (3)]

Looks like the yoke is either id=11 or id=12 so I blindly tried xinput set-prop 11 266 0 etc. but get an error "property 266 doesn't exist ...". It is interesting that I also have the Saitek foot pedals but they don't seem to cause any problems. Why is it that the yoke is being treated and a mouse and the foot pedals aren't?

Here are my USB devices if of any help.

darrell@beeker:~$ lsusb
Bus 008 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 008 Device 002: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 046d:c308 Logitech, Inc. Internet Navigator Keyboard
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 03f0:0601 Hewlett-Packard ScanJet 6300c
Bus 003 Device 002: ID 0461:4d0f Primax Electronics, Ltd
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 038: ID 06a3:0bac Saitek PLC
Bus 001 Device 037: ID 06a3:712c Saitek PLC
Bus 001 Device 020: ID 06a3:0763 Saitek PLC
Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Any help appreciated!

Sorry, my bad. Your device might have different properties map.

After you:
user@localhost:~$ xinput --list

and find the correct device_id you should:
user@localhost:~$ xinput --list-props device_id

then find correct properties identifiers (in parenthesis) and use it instead of 266 and 267 in my example.

If `xinput --list` doesnt work for you, try `xinput list`, the same with `--list-props`.

Thanks so much trespasser! Using xinput --list-props 11 I see that this Saitek yoke has properties 277 (generate mouse events) and 278 (generate keyboard events). So, I did as you said and it now works great.

  darrell@beeker:~$ xinput set-prop 11 277 0
  darrell@beeker:~$ xinput set-prop 11 278 0

It's so easy when somebody tells you how to do it ... :-)

I am guessing that the prop identifiers are associated with a particular hardware device so should be constant? What about the device_id? Would that be constant for a given system or change every reboot?

Since you're obviously knowledgeable in these matters, is this expected behavior? This sort of thing wasn't necessary in the past so I am thinking this is a bug that should be reported.

Based on trespasser's guidance, here is a script that other users might find useful:

#!/bin/bash
# find the device_id of the Saitek yoke that is a pointer type device
DEV_ID=$(xinput --list | egrep Saitek.*pointer | cut -d "=" -f 2 | cut -f 1)
echo "Found Saitek pointing device with dev_id = $DEV_ID"
# find the mouse event and then disable it
PROP_ID=$(xinput --list-props $DEV_ID | grep "Generate Mouse" | cut -d "(" -f 2 | cut -d ")" -f 1)
echo "Disabling Generate Mouse event (prop $PROP_ID)"
xinput --set-prop $DEV_ID $PROP_ID 0
# and the key event and disable it
PROP_ID=$(xinput --list-props $DEV_ID | grep "Generate Key" | cut -d "(" -f 2 | cut -d ")" -f 1)
echo "Disabling Generate Key event (prop $PROP_ID)"
xinput --set-prop $DEV_ID $PROP_ID 0

I run it manually because I find that the Saitek devices are not connected automatically at startup in Ubuntu 10.10. Although they are present when executing lsusb they don't show up as joystick devices until they are unplugged once. Another one of those little annoyances introduced in the Ubuntu update ...

> I am guessing that the prop identifiers are associated with a particular hardware device so should be constant?
Probably. Usually devices have the same amount of properties and those should be always mapped in the same order as the USB driver always checks for those in the same order. I think the only difference might be for devices that have analog switch disabling/enabling additional axis, etc. In such case some enabled property may "jump in" moving other one "down" on the list.

> What about the device_id? Would that be constant for a given system or change every reboot?
It can change. It depends on when which device is discovered so it will be mostly the same if you have legacy USB support enabled in you mainboard's BI/OS and you do not plug or unplug any USB devices between restarts but otherwise it's a roulette.

> here is a script that other users might find useful
Your script works and it covers above mentioned device ID or property ID changes. It's pretty neat actually that you shared, thank you. I'd use very similar idea but instead of calling `xinput --list-props $DEV_ID` several times I save it to string variable and process later on. Also during processing this string I'd use a `for` loop to actually assign 0 or 1 to any number of properties I specify in a separate device profile containing device name and an array of properties I want to turn off or on. But eventually I'm to lazy to write it so I ended up with a keyboard shortcut calling everything as a one long inline command. ;) I also promissed myself to make it better some day but since it works I probably won't.

> I find that the Saitek devices are not connected automatically at startup
Either your legacy USB support is disabled or something delays your USB driver. The latter is low level init stuff I'd not mess with without better understanding of what happens.

> Although they are present when executing lsusb they don't show up as joystick devices until they are unplugged once
Probably Saitek fault - fully normalized device BI/OS shouldn't act like that.

> Another one of those little annoyances introduced in the Ubuntu update
I think I had this problem with USB devices back in Dapper. AFAICT nothing changed in this area but other subjects of USB driver has been greatly improved. The problem of some devices properties is USB driver wants to fully support the device and if it's capable to provide some functionality it's turned on by default. The only alternative would be to build support for device profiles upstream in USB driver but I'm not willing to do so because:
A. I have no time,
B. it would take a great deal to keep those profiles update and some devices may need more than one for same device name (e.g. mentioned above in this message devices with analog switches changing some modes of particular controller),
C. driver itself would grow huge and need great amount of system resources (just like in Windows family OS-es; I wouldn't like it.

Cheers!