What I've expected: Controller should appear as XI2 device, but not attached to core devices (pointer/keyboard), should just pass kernel input events through. Reading kernel input devices directly is usually not an option for application, as device permissions don't allow that. What I've got: Controller is affecting mouse, badly. In case of Xbox 360 controller mouse is stuck in top left corner of the screen as soon as I've touched a stick on controller. In case of PS3 controller mouse doesn't go crazy, but it moves "rectangular", I cannot perform a circle motion by turning controller's stick around. Why that's important: To make games a better story on X11.
Can you just use evdev rather than the joystick driver? Regarding the discritization of the analog stick, are you sure that the kernel is providing the correct data?
If xf86-input-joystick isn't installed, then controllers do not seem to appear as XI2 devices at all. At least "xinput list" doesn't report them. How can I check kernel input data? Is there an utility or code example?
I was under the impression that most HID gamepads and joysticks were supported by the kernel's generic input event subsystem. I would use evtest to test the gamepad's /dev/input/eventX (http://people.freedesktop.org/~whot/evtest). If there is no /dev/input/eventX node associated with the device, you might want to look into providing kernel support for it.
They are indeed supported. I've used evtest to successfully obtain events from both X360 and PS3 controllers. They report things differently, though. For instance, X360 controller driver reports values for sticks in range -32768..32768, while PS3 one reports 0..255. Also, many buttons on PS3 controller are pressure-sensitive and are reported as axes. But the question of this bug is how to get them working in X11 application? :)
Apparently, I've just realized that gamepad input devices are available to my user (non-root), and seemingly via access control lists. I'm not really an expert of how this works, so why mouse and keyboard are not accessible while gamepads are? Also, is there a support for outputting data to "input device"? I mean, there is an indicator on it, which specifies number of this gamepad, from 1 to 4 (useful in case of multiple gamepads connected), and also there is a rumble (vibration) feature. Is it possible to make use of that?
I haven't hacked on linux in about 5 years, so hopefully someone else can fill in the blanks, but my understanding is that you should be using the evdev driver since these input devices can be accessed with the /dev/input/eventX nodes. I *believe* the joystick driver is for the legacy (pre /dev/input/eventX) interface. I suggest you try using the evdev driver with your gamepads. As for specifics about rumble, etc ... that's out of my area of expertise, but you can probably get support like that from the xorg mailing list since it sounds like this is more of a support question than a bug. Based on that, I'm closing this as not a bug. If it turns out that evdev doesn't work for you, please reopen with additional information. Thanks.
(In reply to comment #6) > I haven't hacked on linux in about 5 years, so hopefully someone else can fill > in the blanks, but my understanding is that you should be using the evdev > driver since these input devices can be accessed with the /dev/input/eventX > nodes. > > I *believe* the joystick driver is for the legacy (pre /dev/input/eventX) > interface. I suggest you try using the evdev driver with your gamepads. a few things, just FYI: - wacom, synaptics, evdev and joystick all use the kernel's evdev interface for most devices. They may have other interfaces, but they're secondary. - evdev is primarily a pointer/keyboard driver and simply ignores devices that don't have the required buttons. somewhere in evdev we have a loop that stops at the first joystick button and simply bails out. so remotes, gamepads, etc. all aren't recognised by evdev. If you're using the joystick driver then yes, the device should be floating from the start. But without a log and a conf, I can't really say more than that.
Well, let's say it other way: Should I use /dev/input/eventX directly, or is it supposed to be exposed with XI2? If not, them I'm just fine with eventX files (since as I've discovered, they're readable by normal user).
I can't recommend using /dev/input/event directly, use XI2 (or whatever toolkit) instead.
OK, if XI2 is the way to go, then we're back to initial state of this bug. Without xf86-input-joystick, no XI2 devices for gamepads, with it - there are XI2 devices, but attached to X core devices, which should NOT happen, because gamepads are not supposed to be used as a mouse. Reopening, as the problem remains unresolved.
xorg.conf and xorg.log please
Created attachment 53066 [details] Xorg configs (xorg.conf and xorg.conf.d)
Created attachment 53067 [details] evtest capture of the device
Created attachment 53068 [details] Xorg.log without xf86-input-joystick
Created attachment 53069 [details] Xorg.log with xf86-input-joystick
Created attachment 53070 [details] "xinput list" output
Put a InputClass in for the 360 pad that adds Option "Floating" "on" and that should fix it.
This should not require additional configuration from user.
I think we agree that it shouldn't. That's why the bug is still open. Can you please confirm that adding the floating option does indeed fix the problem for you?
Adding this to /etc/X11/xorg.conf.d/10-evdev.conf Section "InputClass" Identifier "evdev joystick catchall" MatchIsJoystick "on" MatchDevicePath "/dev/input/event*" Option "Floating" "on" EndSection made the pad floating: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Microsoft Comfort Curve Keyboard 2000 id=11 [slave pointer (2)] ⎜ ↳ Logitech USB-PS/2 Optical Mouse id=12 [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)] ↳ Microsoft Comfort Curve Keyboard 2000 id=10 [slave keyboard (3)] ↳ Eee PC WMI hotkeys id=13 [slave keyboard (3)] ∼ Microsoft X-Box 360 pad (keys) id=8 [floating slave] ∼ Microsoft X-Box 360 pad id=9 [floating slave] But I'm not sure about if it really works. "xinput test-xi2 9" didn't report me any events, and "xinput query-state 9" only seems to report button states (no values from analog sticks). What is the correct way to test XI2 device? And, by the way, does XI2 support force-feedback (for rumble)?
The joystick driver always was supposed to make the joystick available as a X11 input device reporting mouse and key events, before XI2 even was available. So it's primary function was to move around the cursor, which is derived from the position of the axes and time. Later the possibility to get the raw data using XI2 was added, but the first two valuators will always be the relative mouse movement (see the joystick man page on how to make the other axes valuators available). Setting the device floating, you can test it with "xinput test <id>" (not "xinput test-xi2 <id>"). So far games usually opened /dev/input/js* or /dev/input/input* and there might some work left on the joystick driver to make it generically expose all features from the kernel. As I said, so far it never was supposed to.
Sascha, I'm assigning this bug to you then. I don't really want evdev to end up as generic joystick driver at this point (ETIME), maybe there's a few quick fixes for the joystick driver to get it working with this particular device (even if a Floating option must be manually added to the config).
I am interested in using these controllers as regular input devices, I have spent some time configuring both to be awesome computer navigation devices, complete with ctrl, alt, shift, tab, del, enter, space(for selection of items), backspace, esc, arrows, plus the three mouse buttons. They excel at navigation and, with a program like dasher, can even be used for typing. I say this because, unlike Mad Fish, I am not interested in games, but would like to hit on the following: >>In case of PS3 controller mouse doesn't go crazy, but it moves "rectangular", I cannot perform a circle motion by turning controller's stick around. I experience this too, and it bugs me greatly. I believe I understand why it is, and have a theory on how to fix it. Correct me if I am wrong (I have not looked at the code), but isn't this a function of the deadzone? Seems like if the deadzone were per axis, and not a true circular deadzone in the center, it would cause this. If that is the case, it should be fixable by creating a true deadzone through the use of a vector. i.e., figure the magnitude, subtract the deadzone, if it's less than 1, be done, else figure the angle and covert back to x/y values.
(In reply to comment #23) > >>In case of PS3 controller mouse doesn't go crazy, but it moves > "rectangular", I cannot perform a circle motion by turning controller's stick > around. > > I experience this too, and it bugs me greatly. I believe I understand why it > is, and have a theory on how to fix it. Correct me if I am wrong (I have not > looked at the code), but isn't this a function of the deadzone? Seems like > if the deadzone were per axis, and not a true circular deadzone in the > center, it would cause this. It indeed uses a rectangular deadzone, which does affect the circularity, but that effect is too small to matter. Most joysticks have a rectangular field and the kernel separately reports values for x and y, so most of the time you won't have circular events but square ones. Assume the range goes from -1.0 to 1.0, which in the end is simply added up. Moving the axis to the top-left will move 1.0 to the left and 1.0 to the top, resulting in total motion of 2.0, instead of the probably expected 1.4142 (on a square field). I know that the XBox controller in fact has a circular field, on which the kernel would (I suppose) report a top-left position of 0.707, which will result in 1.414 when added up. Using pythagoras would result in the expected 1.0. Plus, the interpolation per axis from the values 0.0 to 1.0 is between linear and square and is based on my experience and personal judgment, which makes it harder to get circular movement. I will create you a patch that uses a better and more precise mathematical calculation of the movement so you can see, if that meets your expectations for circular movement.
(In reply to comment #20) > And, by the way, does XI2 support force-feedback (for rumble)? As far as I know, XI2 does not support feedbacks (XI1 is supposed to do), but no input module is available to send force-feedback events to the physical device. I'd like to put some research and coding in this, if I had an actual device. It's on my list.
latest git (release xf86-input-joystick-1.6.2) contains two commits, that should fix these issues: 342057bf38e fixes axes of the XBox 365 controller behaving completely erratic 819ba33c9d7 tunes the acceleration and ability for circular movement on joysticks, that have a circular axis field. doing circular movement should be much easier while still having a noticeable acceleration.
closing. please reopen if still having issues.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.