Linux gamepad - no input events
up vote
1
down vote
favorite
I'm trying to use a gamepad under linux (kernel is 4.16.10) and I don't seem to get any input events out of it.
The device, a fake xbox 360 controller, seems to be detected as dmesg
seems to report:
#dmesg when pluging in controller
[29505.029981] usb 1-2: new full-speed USB device number 29 using xhci_hcd
[29505.158111] usb 1-2: New USB device found, idVendor=2563, idProduct=0575
[29505.158116] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29505.158119] usb 1-2: Product: PS3/PC Gamepad
[29505.158121] usb 1-2: Manufacturer: SHANWAN
[29505.160469] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:2563:0575.000D/input/input52
[29505.160604] hid-generic 0003:2563:0575.000D: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:00:14.0-2/input0
[29505.238365] usb 1-2: USB disconnect, device number 29
[29505.845839] usb 1-2: new full-speed USB device number 30 using xhci_hcd
[29505.974584] usb 1-2: New USB device found, idVendor=045e, idProduct=028e
[29505.974590] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29505.974594] usb 1-2: Product: Controller
[29505.974598] usb 1-2: Manufacturer: SHANWAN
[29505.976469] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input53
I tried with both evdev
and joystick
drivers:
# /var/log/x-0.log with joystick driver
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/event7)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'joystick' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) Microsoft X-Box 360 pad (keys): Applying InputClass "joystick catchall"
(II) Using input driver 'joystick' for 'Microsoft X-Box 360 pad (keys)'
(**) Microsoft X-Box 360 pad (keys): always reports core events
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input55/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad (keys)" (type: JOYSTICK, id 18)
(**) Option "Device" "/dev/input/event7"
(**) Option "StartMouseEnabled" "False"
(**) Option "StartKeysEnabled" "False"
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input55/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad" (type: JOYSTICK, id 19)
(II) Joystick: Microsoft X-Box 360 pad. bus 0x3 vendor 0x45e product 0x28e version 0x110
(II) Joystick: found 8 axes, 11 buttons
JOYSTICK: DebugLevel set to 0
(**) Microsoft X-Box 360 pad: (accel) keeping acceleration scheme 1
(**) Microsoft X-Box 360 pad: (accel) acceleration profile 0
(**) Microsoft X-Box 360 pad: (accel) acceleration factor: 2.000
(**) Microsoft X-Box 360 pad: (accel) acceleration threshold: 4
# /var/log/x-0.log with evdev driver
(II) config/udev: removing device Microsoft X-Box 360 pad
(II) evdev: Microsoft X-Box 360 pad: Close
(II) UnloadModule: "evdev"
(II) config/udev: Adding input device SHANWAN PS3/PC Gamepad (/dev/input/js0)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device (unnamed) (/dev/input/event7)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/js0)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'evdev' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) evdev: Microsoft X-Box 360 pad: Device: "/dev/input/js0"
(EE) evdev: Microsoft X-Box 360 pad: Unable to query fd: Invalid argument
(EE) PreInit returned 2 for "Microsoft X-Box 360 pad"
(II) UnloadModule: "evdev"
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/event7)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'evdev' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) evdev: Microsoft X-Box 360 pad: Device: "/dev/input/event7"
(--) evdev: Microsoft X-Box 360 pad: Vendor 0x45e Product 0x28e
(--) evdev: Microsoft X-Box 360 pad: Found absolute axes
(--) evdev: Microsoft X-Box 360 pad: Found x and y absolute axes
(II) evdev: Microsoft X-Box 360 pad: Forcing relative x/y axes to exist.
(II) evdev: Microsoft X-Box 360 pad: Configuring as mouse
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input59/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad" (type: MOUSE, id 16)
(II) evdev: Microsoft X-Box 360 pad: initialized for absolute axes.
(**) Microsoft X-Box 360 pad: (accel) keeping acceleration scheme 1
(**) Microsoft X-Box 360 pad: (accel) acceleration profile 0
(**) Microsoft X-Box 360 pad: (accel) acceleration factor: 2.000
(**) Microsoft X-Box 360 pad: (accel) acceleration threshold: 4
Yet, I'm unable to get any input events neither with jstest
nor evtest
(both as root and non-root). Same with xboxdrv
btw.
usbmon
gets datas only when pluging in and pluging out the controller. Nothing is reported when buttons are pressed.
But evdev
detects sereral possible events:
# evtest
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 304 (BTN_SOUTH)
Event code 305 (BTN_EAST)
Event code 307 (BTN_NORTH)
Event code 308 (BTN_WEST)
Event code 310 (BTN_TL)
Event code 311 (BTN_TR)
Event code 314 (BTN_SELECT)
Event code 315 (BTN_START)
Event code 316 (BTN_MODE)
Event code 317 (BTN_THUMBL)
Event code 318 (BTN_THUMBR)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 1 (ABS_Y)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 2 (ABS_Z)
Value 0
Min 0
Max 255
Event code 3 (ABS_RX)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 4 (ABS_RY)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 5 (ABS_RZ)
Value 0
Min 0
Max 255
Event code 16 (ABS_HAT0X)
Value 0
Min -1
Max 1
Event code 17 (ABS_HAT0Y)
Value 0
Min -1
Max 1
Event type 21 (EV_FF)
Event code 80 (FF_RUMBLE)
Event code 81 (FF_PERIODIC)
Event code 88 (FF_SQUARE)
Event code 89 (FF_TRIANGLE)
Event code 90 (FF_SINE)
Event code 96 (FF_GAIN)
Bonus with Wireshark's usbmon report and a csv with windows counterpart:
https://filebin.net/n416mszk1155zbjb
(sorry but txt versions are indigest)
Does anyone has any idea or lead to find a solution to this problem?
Thanks,
linux xorg game-controller xinput
add a comment |
up vote
1
down vote
favorite
I'm trying to use a gamepad under linux (kernel is 4.16.10) and I don't seem to get any input events out of it.
The device, a fake xbox 360 controller, seems to be detected as dmesg
seems to report:
#dmesg when pluging in controller
[29505.029981] usb 1-2: new full-speed USB device number 29 using xhci_hcd
[29505.158111] usb 1-2: New USB device found, idVendor=2563, idProduct=0575
[29505.158116] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29505.158119] usb 1-2: Product: PS3/PC Gamepad
[29505.158121] usb 1-2: Manufacturer: SHANWAN
[29505.160469] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:2563:0575.000D/input/input52
[29505.160604] hid-generic 0003:2563:0575.000D: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:00:14.0-2/input0
[29505.238365] usb 1-2: USB disconnect, device number 29
[29505.845839] usb 1-2: new full-speed USB device number 30 using xhci_hcd
[29505.974584] usb 1-2: New USB device found, idVendor=045e, idProduct=028e
[29505.974590] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29505.974594] usb 1-2: Product: Controller
[29505.974598] usb 1-2: Manufacturer: SHANWAN
[29505.976469] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input53
I tried with both evdev
and joystick
drivers:
# /var/log/x-0.log with joystick driver
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/event7)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'joystick' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) Microsoft X-Box 360 pad (keys): Applying InputClass "joystick catchall"
(II) Using input driver 'joystick' for 'Microsoft X-Box 360 pad (keys)'
(**) Microsoft X-Box 360 pad (keys): always reports core events
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input55/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad (keys)" (type: JOYSTICK, id 18)
(**) Option "Device" "/dev/input/event7"
(**) Option "StartMouseEnabled" "False"
(**) Option "StartKeysEnabled" "False"
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input55/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad" (type: JOYSTICK, id 19)
(II) Joystick: Microsoft X-Box 360 pad. bus 0x3 vendor 0x45e product 0x28e version 0x110
(II) Joystick: found 8 axes, 11 buttons
JOYSTICK: DebugLevel set to 0
(**) Microsoft X-Box 360 pad: (accel) keeping acceleration scheme 1
(**) Microsoft X-Box 360 pad: (accel) acceleration profile 0
(**) Microsoft X-Box 360 pad: (accel) acceleration factor: 2.000
(**) Microsoft X-Box 360 pad: (accel) acceleration threshold: 4
# /var/log/x-0.log with evdev driver
(II) config/udev: removing device Microsoft X-Box 360 pad
(II) evdev: Microsoft X-Box 360 pad: Close
(II) UnloadModule: "evdev"
(II) config/udev: Adding input device SHANWAN PS3/PC Gamepad (/dev/input/js0)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device (unnamed) (/dev/input/event7)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/js0)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'evdev' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) evdev: Microsoft X-Box 360 pad: Device: "/dev/input/js0"
(EE) evdev: Microsoft X-Box 360 pad: Unable to query fd: Invalid argument
(EE) PreInit returned 2 for "Microsoft X-Box 360 pad"
(II) UnloadModule: "evdev"
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/event7)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'evdev' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) evdev: Microsoft X-Box 360 pad: Device: "/dev/input/event7"
(--) evdev: Microsoft X-Box 360 pad: Vendor 0x45e Product 0x28e
(--) evdev: Microsoft X-Box 360 pad: Found absolute axes
(--) evdev: Microsoft X-Box 360 pad: Found x and y absolute axes
(II) evdev: Microsoft X-Box 360 pad: Forcing relative x/y axes to exist.
(II) evdev: Microsoft X-Box 360 pad: Configuring as mouse
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input59/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad" (type: MOUSE, id 16)
(II) evdev: Microsoft X-Box 360 pad: initialized for absolute axes.
(**) Microsoft X-Box 360 pad: (accel) keeping acceleration scheme 1
(**) Microsoft X-Box 360 pad: (accel) acceleration profile 0
(**) Microsoft X-Box 360 pad: (accel) acceleration factor: 2.000
(**) Microsoft X-Box 360 pad: (accel) acceleration threshold: 4
Yet, I'm unable to get any input events neither with jstest
nor evtest
(both as root and non-root). Same with xboxdrv
btw.
usbmon
gets datas only when pluging in and pluging out the controller. Nothing is reported when buttons are pressed.
But evdev
detects sereral possible events:
# evtest
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 304 (BTN_SOUTH)
Event code 305 (BTN_EAST)
Event code 307 (BTN_NORTH)
Event code 308 (BTN_WEST)
Event code 310 (BTN_TL)
Event code 311 (BTN_TR)
Event code 314 (BTN_SELECT)
Event code 315 (BTN_START)
Event code 316 (BTN_MODE)
Event code 317 (BTN_THUMBL)
Event code 318 (BTN_THUMBR)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 1 (ABS_Y)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 2 (ABS_Z)
Value 0
Min 0
Max 255
Event code 3 (ABS_RX)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 4 (ABS_RY)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 5 (ABS_RZ)
Value 0
Min 0
Max 255
Event code 16 (ABS_HAT0X)
Value 0
Min -1
Max 1
Event code 17 (ABS_HAT0Y)
Value 0
Min -1
Max 1
Event type 21 (EV_FF)
Event code 80 (FF_RUMBLE)
Event code 81 (FF_PERIODIC)
Event code 88 (FF_SQUARE)
Event code 89 (FF_TRIANGLE)
Event code 90 (FF_SINE)
Event code 96 (FF_GAIN)
Bonus with Wireshark's usbmon report and a csv with windows counterpart:
https://filebin.net/n416mszk1155zbjb
(sorry but txt versions are indigest)
Does anyone has any idea or lead to find a solution to this problem?
Thanks,
linux xorg game-controller xinput
Did you connect the device twice during the time of thedmesg
output? The device disconnects, then connects again with different id's, which is odd to say the least, and may indicate a hardware problem. The first variant seems to allow HID access, is the hidraw device still available? If you don't see anything in the input level (withevtest
), next step would be to look at the HID level, and then the USB level.
– dirkt
May 31 at 10:53
Hum, nice catch! I think reconnects itself on purpose to lie about the device (from PS3/PC pad to X-box 360 pad). Is it possible? Anyway, the hidraw device isn't available. :/ Is there any way to deal with that kind of behaviour?
– lHart
May 31 at 13:24
Read up onusbmon
, see if you get USB events from the device at all (in the X-box 360 incarnation). Also, please update question with thesupported events
part from when you startevtest
(as root); based on the X log, something seems to work at least.
– dirkt
May 31 at 20:09
I added usbmon and evdev outputs in main post.
– lHart
Jun 1 at 20:16
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I'm trying to use a gamepad under linux (kernel is 4.16.10) and I don't seem to get any input events out of it.
The device, a fake xbox 360 controller, seems to be detected as dmesg
seems to report:
#dmesg when pluging in controller
[29505.029981] usb 1-2: new full-speed USB device number 29 using xhci_hcd
[29505.158111] usb 1-2: New USB device found, idVendor=2563, idProduct=0575
[29505.158116] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29505.158119] usb 1-2: Product: PS3/PC Gamepad
[29505.158121] usb 1-2: Manufacturer: SHANWAN
[29505.160469] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:2563:0575.000D/input/input52
[29505.160604] hid-generic 0003:2563:0575.000D: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:00:14.0-2/input0
[29505.238365] usb 1-2: USB disconnect, device number 29
[29505.845839] usb 1-2: new full-speed USB device number 30 using xhci_hcd
[29505.974584] usb 1-2: New USB device found, idVendor=045e, idProduct=028e
[29505.974590] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29505.974594] usb 1-2: Product: Controller
[29505.974598] usb 1-2: Manufacturer: SHANWAN
[29505.976469] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input53
I tried with both evdev
and joystick
drivers:
# /var/log/x-0.log with joystick driver
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/event7)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'joystick' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) Microsoft X-Box 360 pad (keys): Applying InputClass "joystick catchall"
(II) Using input driver 'joystick' for 'Microsoft X-Box 360 pad (keys)'
(**) Microsoft X-Box 360 pad (keys): always reports core events
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input55/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad (keys)" (type: JOYSTICK, id 18)
(**) Option "Device" "/dev/input/event7"
(**) Option "StartMouseEnabled" "False"
(**) Option "StartKeysEnabled" "False"
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input55/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad" (type: JOYSTICK, id 19)
(II) Joystick: Microsoft X-Box 360 pad. bus 0x3 vendor 0x45e product 0x28e version 0x110
(II) Joystick: found 8 axes, 11 buttons
JOYSTICK: DebugLevel set to 0
(**) Microsoft X-Box 360 pad: (accel) keeping acceleration scheme 1
(**) Microsoft X-Box 360 pad: (accel) acceleration profile 0
(**) Microsoft X-Box 360 pad: (accel) acceleration factor: 2.000
(**) Microsoft X-Box 360 pad: (accel) acceleration threshold: 4
# /var/log/x-0.log with evdev driver
(II) config/udev: removing device Microsoft X-Box 360 pad
(II) evdev: Microsoft X-Box 360 pad: Close
(II) UnloadModule: "evdev"
(II) config/udev: Adding input device SHANWAN PS3/PC Gamepad (/dev/input/js0)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device (unnamed) (/dev/input/event7)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/js0)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'evdev' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) evdev: Microsoft X-Box 360 pad: Device: "/dev/input/js0"
(EE) evdev: Microsoft X-Box 360 pad: Unable to query fd: Invalid argument
(EE) PreInit returned 2 for "Microsoft X-Box 360 pad"
(II) UnloadModule: "evdev"
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/event7)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'evdev' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) evdev: Microsoft X-Box 360 pad: Device: "/dev/input/event7"
(--) evdev: Microsoft X-Box 360 pad: Vendor 0x45e Product 0x28e
(--) evdev: Microsoft X-Box 360 pad: Found absolute axes
(--) evdev: Microsoft X-Box 360 pad: Found x and y absolute axes
(II) evdev: Microsoft X-Box 360 pad: Forcing relative x/y axes to exist.
(II) evdev: Microsoft X-Box 360 pad: Configuring as mouse
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input59/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad" (type: MOUSE, id 16)
(II) evdev: Microsoft X-Box 360 pad: initialized for absolute axes.
(**) Microsoft X-Box 360 pad: (accel) keeping acceleration scheme 1
(**) Microsoft X-Box 360 pad: (accel) acceleration profile 0
(**) Microsoft X-Box 360 pad: (accel) acceleration factor: 2.000
(**) Microsoft X-Box 360 pad: (accel) acceleration threshold: 4
Yet, I'm unable to get any input events neither with jstest
nor evtest
(both as root and non-root). Same with xboxdrv
btw.
usbmon
gets datas only when pluging in and pluging out the controller. Nothing is reported when buttons are pressed.
But evdev
detects sereral possible events:
# evtest
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 304 (BTN_SOUTH)
Event code 305 (BTN_EAST)
Event code 307 (BTN_NORTH)
Event code 308 (BTN_WEST)
Event code 310 (BTN_TL)
Event code 311 (BTN_TR)
Event code 314 (BTN_SELECT)
Event code 315 (BTN_START)
Event code 316 (BTN_MODE)
Event code 317 (BTN_THUMBL)
Event code 318 (BTN_THUMBR)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 1 (ABS_Y)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 2 (ABS_Z)
Value 0
Min 0
Max 255
Event code 3 (ABS_RX)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 4 (ABS_RY)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 5 (ABS_RZ)
Value 0
Min 0
Max 255
Event code 16 (ABS_HAT0X)
Value 0
Min -1
Max 1
Event code 17 (ABS_HAT0Y)
Value 0
Min -1
Max 1
Event type 21 (EV_FF)
Event code 80 (FF_RUMBLE)
Event code 81 (FF_PERIODIC)
Event code 88 (FF_SQUARE)
Event code 89 (FF_TRIANGLE)
Event code 90 (FF_SINE)
Event code 96 (FF_GAIN)
Bonus with Wireshark's usbmon report and a csv with windows counterpart:
https://filebin.net/n416mszk1155zbjb
(sorry but txt versions are indigest)
Does anyone has any idea or lead to find a solution to this problem?
Thanks,
linux xorg game-controller xinput
I'm trying to use a gamepad under linux (kernel is 4.16.10) and I don't seem to get any input events out of it.
The device, a fake xbox 360 controller, seems to be detected as dmesg
seems to report:
#dmesg when pluging in controller
[29505.029981] usb 1-2: new full-speed USB device number 29 using xhci_hcd
[29505.158111] usb 1-2: New USB device found, idVendor=2563, idProduct=0575
[29505.158116] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29505.158119] usb 1-2: Product: PS3/PC Gamepad
[29505.158121] usb 1-2: Manufacturer: SHANWAN
[29505.160469] input: SHANWAN PS3/PC Gamepad as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:2563:0575.000D/input/input52
[29505.160604] hid-generic 0003:2563:0575.000D: input,hidraw0: USB HID v1.10 Gamepad [SHANWAN PS3/PC Gamepad] on usb-0000:00:14.0-2/input0
[29505.238365] usb 1-2: USB disconnect, device number 29
[29505.845839] usb 1-2: new full-speed USB device number 30 using xhci_hcd
[29505.974584] usb 1-2: New USB device found, idVendor=045e, idProduct=028e
[29505.974590] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29505.974594] usb 1-2: Product: Controller
[29505.974598] usb 1-2: Manufacturer: SHANWAN
[29505.976469] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input53
I tried with both evdev
and joystick
drivers:
# /var/log/x-0.log with joystick driver
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/event7)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'joystick' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) Microsoft X-Box 360 pad (keys): Applying InputClass "joystick catchall"
(II) Using input driver 'joystick' for 'Microsoft X-Box 360 pad (keys)'
(**) Microsoft X-Box 360 pad (keys): always reports core events
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input55/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad (keys)" (type: JOYSTICK, id 18)
(**) Option "Device" "/dev/input/event7"
(**) Option "StartMouseEnabled" "False"
(**) Option "StartKeysEnabled" "False"
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/input/input55/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad" (type: JOYSTICK, id 19)
(II) Joystick: Microsoft X-Box 360 pad. bus 0x3 vendor 0x45e product 0x28e version 0x110
(II) Joystick: found 8 axes, 11 buttons
JOYSTICK: DebugLevel set to 0
(**) Microsoft X-Box 360 pad: (accel) keeping acceleration scheme 1
(**) Microsoft X-Box 360 pad: (accel) acceleration profile 0
(**) Microsoft X-Box 360 pad: (accel) acceleration factor: 2.000
(**) Microsoft X-Box 360 pad: (accel) acceleration threshold: 4
# /var/log/x-0.log with evdev driver
(II) config/udev: removing device Microsoft X-Box 360 pad
(II) evdev: Microsoft X-Box 360 pad: Close
(II) UnloadModule: "evdev"
(II) config/udev: Adding input device SHANWAN PS3/PC Gamepad (/dev/input/js0)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device (unnamed) (/dev/input/event7)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/js0)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'evdev' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) evdev: Microsoft X-Box 360 pad: Device: "/dev/input/js0"
(EE) evdev: Microsoft X-Box 360 pad: Unable to query fd: Invalid argument
(EE) PreInit returned 2 for "Microsoft X-Box 360 pad"
(II) UnloadModule: "evdev"
(II) config/udev: Adding input device Microsoft X-Box 360 pad (/dev/input/event7)
(**) Microsoft X-Box 360 pad: Applying InputClass "joystick catchall"
(II) Using input driver 'evdev' for 'Microsoft X-Box 360 pad'
(**) Microsoft X-Box 360 pad: always reports core events
(**) evdev: Microsoft X-Box 360 pad: Device: "/dev/input/event7"
(--) evdev: Microsoft X-Box 360 pad: Vendor 0x45e Product 0x28e
(--) evdev: Microsoft X-Box 360 pad: Found absolute axes
(--) evdev: Microsoft X-Box 360 pad: Found x and y absolute axes
(II) evdev: Microsoft X-Box 360 pad: Forcing relative x/y axes to exist.
(II) evdev: Microsoft X-Box 360 pad: Configuring as mouse
(**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/input/input59/event7"
(II) XINPUT: Adding extended input device "Microsoft X-Box 360 pad" (type: MOUSE, id 16)
(II) evdev: Microsoft X-Box 360 pad: initialized for absolute axes.
(**) Microsoft X-Box 360 pad: (accel) keeping acceleration scheme 1
(**) Microsoft X-Box 360 pad: (accel) acceleration profile 0
(**) Microsoft X-Box 360 pad: (accel) acceleration factor: 2.000
(**) Microsoft X-Box 360 pad: (accel) acceleration threshold: 4
Yet, I'm unable to get any input events neither with jstest
nor evtest
(both as root and non-root). Same with xboxdrv
btw.
usbmon
gets datas only when pluging in and pluging out the controller. Nothing is reported when buttons are pressed.
But evdev
detects sereral possible events:
# evtest
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 304 (BTN_SOUTH)
Event code 305 (BTN_EAST)
Event code 307 (BTN_NORTH)
Event code 308 (BTN_WEST)
Event code 310 (BTN_TL)
Event code 311 (BTN_TR)
Event code 314 (BTN_SELECT)
Event code 315 (BTN_START)
Event code 316 (BTN_MODE)
Event code 317 (BTN_THUMBL)
Event code 318 (BTN_THUMBR)
Event type 3 (EV_ABS)
Event code 0 (ABS_X)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 1 (ABS_Y)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 2 (ABS_Z)
Value 0
Min 0
Max 255
Event code 3 (ABS_RX)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 4 (ABS_RY)
Value 0
Min -32768
Max 32767
Fuzz 16
Flat 128
Event code 5 (ABS_RZ)
Value 0
Min 0
Max 255
Event code 16 (ABS_HAT0X)
Value 0
Min -1
Max 1
Event code 17 (ABS_HAT0Y)
Value 0
Min -1
Max 1
Event type 21 (EV_FF)
Event code 80 (FF_RUMBLE)
Event code 81 (FF_PERIODIC)
Event code 88 (FF_SQUARE)
Event code 89 (FF_TRIANGLE)
Event code 90 (FF_SINE)
Event code 96 (FF_GAIN)
Bonus with Wireshark's usbmon report and a csv with windows counterpart:
https://filebin.net/n416mszk1155zbjb
(sorry but txt versions are indigest)
Does anyone has any idea or lead to find a solution to this problem?
Thanks,
linux xorg game-controller xinput
linux xorg game-controller xinput
edited Jun 3 at 16:36
asked May 30 at 17:24
lHart
83
83
Did you connect the device twice during the time of thedmesg
output? The device disconnects, then connects again with different id's, which is odd to say the least, and may indicate a hardware problem. The first variant seems to allow HID access, is the hidraw device still available? If you don't see anything in the input level (withevtest
), next step would be to look at the HID level, and then the USB level.
– dirkt
May 31 at 10:53
Hum, nice catch! I think reconnects itself on purpose to lie about the device (from PS3/PC pad to X-box 360 pad). Is it possible? Anyway, the hidraw device isn't available. :/ Is there any way to deal with that kind of behaviour?
– lHart
May 31 at 13:24
Read up onusbmon
, see if you get USB events from the device at all (in the X-box 360 incarnation). Also, please update question with thesupported events
part from when you startevtest
(as root); based on the X log, something seems to work at least.
– dirkt
May 31 at 20:09
I added usbmon and evdev outputs in main post.
– lHart
Jun 1 at 20:16
add a comment |
Did you connect the device twice during the time of thedmesg
output? The device disconnects, then connects again with different id's, which is odd to say the least, and may indicate a hardware problem. The first variant seems to allow HID access, is the hidraw device still available? If you don't see anything in the input level (withevtest
), next step would be to look at the HID level, and then the USB level.
– dirkt
May 31 at 10:53
Hum, nice catch! I think reconnects itself on purpose to lie about the device (from PS3/PC pad to X-box 360 pad). Is it possible? Anyway, the hidraw device isn't available. :/ Is there any way to deal with that kind of behaviour?
– lHart
May 31 at 13:24
Read up onusbmon
, see if you get USB events from the device at all (in the X-box 360 incarnation). Also, please update question with thesupported events
part from when you startevtest
(as root); based on the X log, something seems to work at least.
– dirkt
May 31 at 20:09
I added usbmon and evdev outputs in main post.
– lHart
Jun 1 at 20:16
Did you connect the device twice during the time of the
dmesg
output? The device disconnects, then connects again with different id's, which is odd to say the least, and may indicate a hardware problem. The first variant seems to allow HID access, is the hidraw device still available? If you don't see anything in the input level (with evtest
), next step would be to look at the HID level, and then the USB level.– dirkt
May 31 at 10:53
Did you connect the device twice during the time of the
dmesg
output? The device disconnects, then connects again with different id's, which is odd to say the least, and may indicate a hardware problem. The first variant seems to allow HID access, is the hidraw device still available? If you don't see anything in the input level (with evtest
), next step would be to look at the HID level, and then the USB level.– dirkt
May 31 at 10:53
Hum, nice catch! I think reconnects itself on purpose to lie about the device (from PS3/PC pad to X-box 360 pad). Is it possible? Anyway, the hidraw device isn't available. :/ Is there any way to deal with that kind of behaviour?
– lHart
May 31 at 13:24
Hum, nice catch! I think reconnects itself on purpose to lie about the device (from PS3/PC pad to X-box 360 pad). Is it possible? Anyway, the hidraw device isn't available. :/ Is there any way to deal with that kind of behaviour?
– lHart
May 31 at 13:24
Read up on
usbmon
, see if you get USB events from the device at all (in the X-box 360 incarnation). Also, please update question with the supported events
part from when you start evtest
(as root); based on the X log, something seems to work at least.– dirkt
May 31 at 20:09
Read up on
usbmon
, see if you get USB events from the device at all (in the X-box 360 incarnation). Also, please update question with the supported events
part from when you start evtest
(as root); based on the X log, something seems to work at least.– dirkt
May 31 at 20:09
I added usbmon and evdev outputs in main post.
– lHart
Jun 1 at 20:16
I added usbmon and evdev outputs in main post.
– lHart
Jun 1 at 20:16
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
accepted
If you don't get any USB traffic when pressing buttons, something on the hardware isn't working properly.
Either the hardware is broken, or it needs to be properly initialized during the phase when it announces itself as SHANWAN PS3/PC
, or possibly in the incarnation as Microsoft X-Box 360 pad
it expects initialization commands by the Windows driver which the Linux driver doesn't supply.
Next step would be to connect it to a computer with the proper Windows driver, see if it works there. If no, return it; if yes, sniff the USB traffic (there are Windows tools for this, google) to find out how it should be initialized.
Edit
I still don't understand the mess with the two devices (and didn't have time to look at it in detail). However, one can see that under Windows, the following exchange takes place, before key events are sent:
In: 01 03 02
Out: 01 03 02
In: 02 03 00
Out:
In: 03 03 03
Out:
In: 08 03 00
Out:
Under Linux, only the first line appears; there never is an answer. This could be the missing initialisation (or something else).
While looking at that, I found that xpad
is the kernel driver which translates the HID events to input events, I can't see from your dmesg
extract if it gets loaded. In doube, check with lsmod
. (I couldn't find those sequences during a quick check of the source, though).
There also seems to be a userspace library, see e.g. here, which seems to work better than the kernel driver, so this is also worth a try.
Hum. It works without issues under windows. And it seems to behave the same way (disconnect then reconnect). Not many out messages, what precedes a the event loop are some (raw)01 03 02
that seem to be present under linux as well. But what might be interesting under linux, is that, using wireshark, I found that the last messages arePORT_SUSPEND
(out then in). Is it ok?
– lHart
Jun 2 at 10:51
To guess what's going on, I'd need a complete protocol of a working interaction under Windows, right from when you plug it in, as well as the Linux interaction. Might be some Linux driver oddity that's ok for the original, but not this copy...
– dirkt
Jun 2 at 16:07
Thank you very much for your help. I added logs of usb interactions. I hope the file formats are ok.
– lHart
Jun 3 at 16:38
Updating:xpad
is listed inlsmod
and the problem is the same withxboxdrv
. ;)
– lHart
Jun 6 at 16:25
add a comment |
up vote
0
down vote
I have the same problem, but I managed to identify the initialization sequence of the Windows driver, and based on that I wrote a python script that sends the necessary codes to the device.
This is the script, you must run it with sudo: pyusb-test.py
Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
– bertieb
Dec 2 at 19:12
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
If you don't get any USB traffic when pressing buttons, something on the hardware isn't working properly.
Either the hardware is broken, or it needs to be properly initialized during the phase when it announces itself as SHANWAN PS3/PC
, or possibly in the incarnation as Microsoft X-Box 360 pad
it expects initialization commands by the Windows driver which the Linux driver doesn't supply.
Next step would be to connect it to a computer with the proper Windows driver, see if it works there. If no, return it; if yes, sniff the USB traffic (there are Windows tools for this, google) to find out how it should be initialized.
Edit
I still don't understand the mess with the two devices (and didn't have time to look at it in detail). However, one can see that under Windows, the following exchange takes place, before key events are sent:
In: 01 03 02
Out: 01 03 02
In: 02 03 00
Out:
In: 03 03 03
Out:
In: 08 03 00
Out:
Under Linux, only the first line appears; there never is an answer. This could be the missing initialisation (or something else).
While looking at that, I found that xpad
is the kernel driver which translates the HID events to input events, I can't see from your dmesg
extract if it gets loaded. In doube, check with lsmod
. (I couldn't find those sequences during a quick check of the source, though).
There also seems to be a userspace library, see e.g. here, which seems to work better than the kernel driver, so this is also worth a try.
Hum. It works without issues under windows. And it seems to behave the same way (disconnect then reconnect). Not many out messages, what precedes a the event loop are some (raw)01 03 02
that seem to be present under linux as well. But what might be interesting under linux, is that, using wireshark, I found that the last messages arePORT_SUSPEND
(out then in). Is it ok?
– lHart
Jun 2 at 10:51
To guess what's going on, I'd need a complete protocol of a working interaction under Windows, right from when you plug it in, as well as the Linux interaction. Might be some Linux driver oddity that's ok for the original, but not this copy...
– dirkt
Jun 2 at 16:07
Thank you very much for your help. I added logs of usb interactions. I hope the file formats are ok.
– lHart
Jun 3 at 16:38
Updating:xpad
is listed inlsmod
and the problem is the same withxboxdrv
. ;)
– lHart
Jun 6 at 16:25
add a comment |
up vote
0
down vote
accepted
If you don't get any USB traffic when pressing buttons, something on the hardware isn't working properly.
Either the hardware is broken, or it needs to be properly initialized during the phase when it announces itself as SHANWAN PS3/PC
, or possibly in the incarnation as Microsoft X-Box 360 pad
it expects initialization commands by the Windows driver which the Linux driver doesn't supply.
Next step would be to connect it to a computer with the proper Windows driver, see if it works there. If no, return it; if yes, sniff the USB traffic (there are Windows tools for this, google) to find out how it should be initialized.
Edit
I still don't understand the mess with the two devices (and didn't have time to look at it in detail). However, one can see that under Windows, the following exchange takes place, before key events are sent:
In: 01 03 02
Out: 01 03 02
In: 02 03 00
Out:
In: 03 03 03
Out:
In: 08 03 00
Out:
Under Linux, only the first line appears; there never is an answer. This could be the missing initialisation (or something else).
While looking at that, I found that xpad
is the kernel driver which translates the HID events to input events, I can't see from your dmesg
extract if it gets loaded. In doube, check with lsmod
. (I couldn't find those sequences during a quick check of the source, though).
There also seems to be a userspace library, see e.g. here, which seems to work better than the kernel driver, so this is also worth a try.
Hum. It works without issues under windows. And it seems to behave the same way (disconnect then reconnect). Not many out messages, what precedes a the event loop are some (raw)01 03 02
that seem to be present under linux as well. But what might be interesting under linux, is that, using wireshark, I found that the last messages arePORT_SUSPEND
(out then in). Is it ok?
– lHart
Jun 2 at 10:51
To guess what's going on, I'd need a complete protocol of a working interaction under Windows, right from when you plug it in, as well as the Linux interaction. Might be some Linux driver oddity that's ok for the original, but not this copy...
– dirkt
Jun 2 at 16:07
Thank you very much for your help. I added logs of usb interactions. I hope the file formats are ok.
– lHart
Jun 3 at 16:38
Updating:xpad
is listed inlsmod
and the problem is the same withxboxdrv
. ;)
– lHart
Jun 6 at 16:25
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
If you don't get any USB traffic when pressing buttons, something on the hardware isn't working properly.
Either the hardware is broken, or it needs to be properly initialized during the phase when it announces itself as SHANWAN PS3/PC
, or possibly in the incarnation as Microsoft X-Box 360 pad
it expects initialization commands by the Windows driver which the Linux driver doesn't supply.
Next step would be to connect it to a computer with the proper Windows driver, see if it works there. If no, return it; if yes, sniff the USB traffic (there are Windows tools for this, google) to find out how it should be initialized.
Edit
I still don't understand the mess with the two devices (and didn't have time to look at it in detail). However, one can see that under Windows, the following exchange takes place, before key events are sent:
In: 01 03 02
Out: 01 03 02
In: 02 03 00
Out:
In: 03 03 03
Out:
In: 08 03 00
Out:
Under Linux, only the first line appears; there never is an answer. This could be the missing initialisation (or something else).
While looking at that, I found that xpad
is the kernel driver which translates the HID events to input events, I can't see from your dmesg
extract if it gets loaded. In doube, check with lsmod
. (I couldn't find those sequences during a quick check of the source, though).
There also seems to be a userspace library, see e.g. here, which seems to work better than the kernel driver, so this is also worth a try.
If you don't get any USB traffic when pressing buttons, something on the hardware isn't working properly.
Either the hardware is broken, or it needs to be properly initialized during the phase when it announces itself as SHANWAN PS3/PC
, or possibly in the incarnation as Microsoft X-Box 360 pad
it expects initialization commands by the Windows driver which the Linux driver doesn't supply.
Next step would be to connect it to a computer with the proper Windows driver, see if it works there. If no, return it; if yes, sniff the USB traffic (there are Windows tools for this, google) to find out how it should be initialized.
Edit
I still don't understand the mess with the two devices (and didn't have time to look at it in detail). However, one can see that under Windows, the following exchange takes place, before key events are sent:
In: 01 03 02
Out: 01 03 02
In: 02 03 00
Out:
In: 03 03 03
Out:
In: 08 03 00
Out:
Under Linux, only the first line appears; there never is an answer. This could be the missing initialisation (or something else).
While looking at that, I found that xpad
is the kernel driver which translates the HID events to input events, I can't see from your dmesg
extract if it gets loaded. In doube, check with lsmod
. (I couldn't find those sequences during a quick check of the source, though).
There also seems to be a userspace library, see e.g. here, which seems to work better than the kernel driver, so this is also worth a try.
edited Jun 3 at 18:53
answered Jun 2 at 4:38
dirkt
8,92731121
8,92731121
Hum. It works without issues under windows. And it seems to behave the same way (disconnect then reconnect). Not many out messages, what precedes a the event loop are some (raw)01 03 02
that seem to be present under linux as well. But what might be interesting under linux, is that, using wireshark, I found that the last messages arePORT_SUSPEND
(out then in). Is it ok?
– lHart
Jun 2 at 10:51
To guess what's going on, I'd need a complete protocol of a working interaction under Windows, right from when you plug it in, as well as the Linux interaction. Might be some Linux driver oddity that's ok for the original, but not this copy...
– dirkt
Jun 2 at 16:07
Thank you very much for your help. I added logs of usb interactions. I hope the file formats are ok.
– lHart
Jun 3 at 16:38
Updating:xpad
is listed inlsmod
and the problem is the same withxboxdrv
. ;)
– lHart
Jun 6 at 16:25
add a comment |
Hum. It works without issues under windows. And it seems to behave the same way (disconnect then reconnect). Not many out messages, what precedes a the event loop are some (raw)01 03 02
that seem to be present under linux as well. But what might be interesting under linux, is that, using wireshark, I found that the last messages arePORT_SUSPEND
(out then in). Is it ok?
– lHart
Jun 2 at 10:51
To guess what's going on, I'd need a complete protocol of a working interaction under Windows, right from when you plug it in, as well as the Linux interaction. Might be some Linux driver oddity that's ok for the original, but not this copy...
– dirkt
Jun 2 at 16:07
Thank you very much for your help. I added logs of usb interactions. I hope the file formats are ok.
– lHart
Jun 3 at 16:38
Updating:xpad
is listed inlsmod
and the problem is the same withxboxdrv
. ;)
– lHart
Jun 6 at 16:25
Hum. It works without issues under windows. And it seems to behave the same way (disconnect then reconnect). Not many out messages, what precedes a the event loop are some (raw)
01 03 02
that seem to be present under linux as well. But what might be interesting under linux, is that, using wireshark, I found that the last messages are PORT_SUSPEND
(out then in). Is it ok?– lHart
Jun 2 at 10:51
Hum. It works without issues under windows. And it seems to behave the same way (disconnect then reconnect). Not many out messages, what precedes a the event loop are some (raw)
01 03 02
that seem to be present under linux as well. But what might be interesting under linux, is that, using wireshark, I found that the last messages are PORT_SUSPEND
(out then in). Is it ok?– lHart
Jun 2 at 10:51
To guess what's going on, I'd need a complete protocol of a working interaction under Windows, right from when you plug it in, as well as the Linux interaction. Might be some Linux driver oddity that's ok for the original, but not this copy...
– dirkt
Jun 2 at 16:07
To guess what's going on, I'd need a complete protocol of a working interaction under Windows, right from when you plug it in, as well as the Linux interaction. Might be some Linux driver oddity that's ok for the original, but not this copy...
– dirkt
Jun 2 at 16:07
Thank you very much for your help. I added logs of usb interactions. I hope the file formats are ok.
– lHart
Jun 3 at 16:38
Thank you very much for your help. I added logs of usb interactions. I hope the file formats are ok.
– lHart
Jun 3 at 16:38
Updating:
xpad
is listed in lsmod
and the problem is the same with xboxdrv
. ;)– lHart
Jun 6 at 16:25
Updating:
xpad
is listed in lsmod
and the problem is the same with xboxdrv
. ;)– lHart
Jun 6 at 16:25
add a comment |
up vote
0
down vote
I have the same problem, but I managed to identify the initialization sequence of the Windows driver, and based on that I wrote a python script that sends the necessary codes to the device.
This is the script, you must run it with sudo: pyusb-test.py
Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
– bertieb
Dec 2 at 19:12
add a comment |
up vote
0
down vote
I have the same problem, but I managed to identify the initialization sequence of the Windows driver, and based on that I wrote a python script that sends the necessary codes to the device.
This is the script, you must run it with sudo: pyusb-test.py
Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
– bertieb
Dec 2 at 19:12
add a comment |
up vote
0
down vote
up vote
0
down vote
I have the same problem, but I managed to identify the initialization sequence of the Windows driver, and based on that I wrote a python script that sends the necessary codes to the device.
This is the script, you must run it with sudo: pyusb-test.py
I have the same problem, but I managed to identify the initialization sequence of the Windows driver, and based on that I wrote a python script that sends the necessary codes to the device.
This is the script, you must run it with sudo: pyusb-test.py
answered Dec 2 at 18:21
DN Modder
1
1
Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
– bertieb
Dec 2 at 19:12
add a comment |
Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
– bertieb
Dec 2 at 19:12
Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
– bertieb
Dec 2 at 19:12
Welcome to Super User! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
– bertieb
Dec 2 at 19:12
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1327267%2flinux-gamepad-no-input-events%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Did you connect the device twice during the time of the
dmesg
output? The device disconnects, then connects again with different id's, which is odd to say the least, and may indicate a hardware problem. The first variant seems to allow HID access, is the hidraw device still available? If you don't see anything in the input level (withevtest
), next step would be to look at the HID level, and then the USB level.– dirkt
May 31 at 10:53
Hum, nice catch! I think reconnects itself on purpose to lie about the device (from PS3/PC pad to X-box 360 pad). Is it possible? Anyway, the hidraw device isn't available. :/ Is there any way to deal with that kind of behaviour?
– lHart
May 31 at 13:24
Read up on
usbmon
, see if you get USB events from the device at all (in the X-box 360 incarnation). Also, please update question with thesupported events
part from when you startevtest
(as root); based on the X log, something seems to work at least.– dirkt
May 31 at 20:09
I added usbmon and evdev outputs in main post.
– lHart
Jun 1 at 20:16