This is a continuation of [#196617](https://bugzilla.kernel.org/show_bug.cgi?id=196617). Visit that thread to see the reason for a second thread (your browser may crash). The PS3 controller's gamepad is treated as a second device after the motion sensor (ie. /dev/input/js0 = motion sensors and /dev/input/js1 = gamepad, #2 LED illuminated on 1st controller, etc.). This causes problems with many applications expecting the first controller to be the gamepad. Here is dmesg output related to the problem: [ 566.837363] input: Sony PLAYSTATION(R)3 Controller Motion Sensors as /devices/pci0000:00/0000:00:14.0/usb3/3-11/3-11:1.0/0003:054C:0268.0005/input/input21 [ 566.891671] input: Sony PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:14.0/usb3/3-11/3-11:1.0/0003:054C:0268.0005/input/input20
We will no longer attach joydev to the input device representing accelerometer on PlayStation controllers, please try 4.14-rc6.
Results of testing linux-4.14-rc6: Only one entry per gamepad is created as /dev/input/jsX, however, two event entries are created, /dev/input/eventX and /dev/input/eventX+1 On linux 4.11.x, only a single "jsX" entry is created and only a single "event" entry is created per gamepad connected. On linux 4.13.8, two "jsX" and two "eventX" entries are created per gamepad. As of linux 4.14-rc6 I am still unable to use "xboxdrv" with the sixaxis controllers, as I am able to do using linux-4.11.
Yes, the PS controllers are composite devices, they will continue be represented as a collection of input devices, all tagged appropriately (i.e. one of them is tagged as INPUT_PROP_ACCELEROMETER). The reason for it is that we can not continue inventing and adding new absolute axes to the input API when manufacturers put more features into their controllers (we have devices with accelerometers, touch interfaces, next maybe they will add magnetometers into the same package), so we have to split them up and have userspace "reassemble" them.
Ok, so this behaviour is intentional and the kernel driver is now working as intended, correct? The principle you describe makes full sense to me, as gamepads evolve, the input features should scale with them. This sounds like a great approach. However, since this change is supposed to "break" userspace, could I be so bold as to suggest moving it to linux-4.15? Since linux-4.14 will be an LTS release, this should provide userspace devs some time to adjust to the new and improved paradigm. I did not yet get the chance to test many things, but none of what I have experimented has worked thus far (but admittedly, I have yet to tweak configs for the new multiple events). Do you think this makes any sense, or should the new features go forth full force with 4.14? Thank you for considering this idea.
(In reply to Dmitry Torokhov from comment #3) > The reason for it is that we can not continue inventing and adding > new absolute axes to the input API when manufacturers put more features into > their controllers (we have devices with accelerometers, touch interfaces, > next > maybe they will add magnetometers into the same package), so we have to split > them up and have userspace "reassemble" them. That's quite a different approach than I had in mind in bug 195643, but I guess it should make more sense too. So, can we expect every button to be exposed again somehow someway in the foreseeable future?
This approach has worked surprisingly well with userspace programs such as "xboxdrv" and "Gens-GS". The buttons had to be remapped, but other than that everything is working exactly as expected. Since the original bug has been resolved, I would recommend closing this issue. For discussing the "why" of this bug, I think bug 195643 is more adequate.