I'm talking about this: https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/commit/?h=for-linus&id=e19a267b9987135c00155a51e683e434b9abb56b Or if the problem is that it totally breaks gamepad API, try to make an extension to this? Use-case is actually represented by emulators of original systems. I have also seen some brave developer add support for them in their (Windows) games/mods, though I wouldn't know about the state of wine. Could somebody CC roderick? And I hope it's not too unorthodox to anticipate discussion on not yet even merged commits (but hey, I see it already landed in system maintainer tree, so..)
The best way would be to locate linux-input mailing list archive (you may try gmane) and reply to the original patch mail. linux-input is not moderated, there is no need to subscribe, just take care not use HTML in e-mail (plain text only, or messages will be dropped).
Wow, seriously ? After >10 years of non-support Sony has decided to "help" by removing software support of feature that they removed in hardware of newest DualShock gamepad model ? A feature that is essential for PS2 & 3 emulation and may be quite useful for remote-controlling PCs (which I, personally, always do) or even robotics. And motion control too ? Which may work wonders for quick aim adjustment like one on VR headsets ? This seems more like an attempt to hide feature downgrade together with EOL'ed model. I would say that if "the Linux spec" arbitrarily doesn't allow an input device to control all of its very real hardware axises then it a problem for "the spec" and not a device. Properly fixing this deficiency in Linux may ease support for other potential multi-axis input hardware which I really would love to see more. Unfortunately, today even real-life military tank-robots (such as Russian Uran-9 UCGV) are controlled by cheap digital-only gamepads: https://www.youtube.com/watch?v=vrNlIAMvlpM&t=17m39s&list=PLcRxMIXa98X-ejsnO4f6yOzKRSht944jW
So.. I'm not 100% sure whether roderick was talking about gamepad api or evdev itself with "input framework", but I have read reports about the later supporting only some handful of axis, so I'll go with it.
http://blog.wooting.nl/analog-input-technologies-for-keyboards/ I just came to realize, it's not just DS3 that has odd analog values attached to otherwise normally digital buttons.
Thanks for reporting. It indeed looks like the Wooting One / Two are analog keyboards. They expose standard key presses, but apparently support analog as well. Analog is not a native feature in keyboard APIs, so on Windows they expose it through wrappers for xinput/dinput. I have reached out to them to have a discussion about their keyboard. We have ideas on how we would to support this on gamepads, but this keyboard justifies the direction we are considering. If we were to help out on this it would take a while, but we are looking at it.
Aimpad (also used by Coolermaster) tech should do the same. Not sure instead about Roccat's Force FX..
There were a number of games that made great use of analog buttons for PlayStation 2 (https://www.thegamer.com/playstation-games-use-pressure-sensitive-face-buttons). I'd love to have access to the same functionality on my desktop.
To be extremely fair, it turns out this is actually already kinda possible through HIDAPI. https://github.com/libsdl-org/SDL/issues/5148 The question if any is, whether a less.. custom/hardcoded approach isn't instead desirable for this purpose. Like, it's not really mundane, but at the same time "button with a digital state, and also an analog reading" is not exactly niche to a single device either.
In my case, I'd like to be able to use it from the Gamepad API for web. The interface exposed already supports a fractional value for buttons[0], not just a boolean, so I speculate it could work if a fractional value was propagated instead of only de/pressed state. I'd like to use the functionality to develop gameplay mechanics like those in the article I linked to. [0] https://www.w3.org/TR/gamepad/#dom-gamepadbutton-value