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
Interestingly enough, there was this proposal all along https://patchwork.kernel.org/project/linux-input/patch/1DD62093774CEE42AFC16E785A1088049E38CBF6@USCULXMSG13.am.sony.com/ https://patchwork.kernel.org/project/linux-input/list/?series=779616
(In reply to mirh from comment #10) > Interestingly enough, there was this proposal all along It sure was. And the whole story is one of the lowest points in FOSS & Linux community history, just like smoke and mirrors of Wayland & FreeDesktop. I remember testing those patches out at some point but then them becoming incompatible with newer kernels or something. I also remember discussion being something of a ridiculous dismissal with "but we don't have enough id numbers in the range for events randomly selected decades ago, so we not going to bother to extend them for devices people might actually care about in the present". I guess, they do not often look away from their 1970s terminals from which they telnet into their headless Linux machines, so they don't know about modern peripherals… or ones from yearly 2000s. In addition to that, DS3 does not use normal way of connecting to BT, so bluez has to have special plugin for it. Which to this day is not even built by some major distros because maintainers there have not heard about the concept of gamepads. Like in openSUSE where BT maintainer said at some point: "but it's not enabled by default, so I'm not going to change options either [or read what they are even for]". Yes, in 2020s major distros' bureaucratic dinosaurs do not know either of the most important input device in all history of gaming… Then Sony guy came to kernel and said: "now we have decided to officially support DualShock… 4, so we are going to gimp hid_sony driver support for DS3 to match castrated features of DS4, [so consumers may be better gaslit into forgetting how we cut it down after yapping for years in advertisements about how cool and important it was]". And that is why to this day we can't just play MGS 3 & 4 in peace on our Linux machines even though emulators supported the whole thing for decades. But at least they did not break motion controls on protocol level too, so those work now.
You should touch some grass I think? Putting aside that DS3 has broken HID, broken connection, and so on and so forth.. As can be read from the cover letter that added its support, the special plugin just exists to provide automatic bluetooth address pairing over *USB* https://www.spinics.net/lists/linux-bluetooth/msg40827.html I can see why code that might even run on the ISS has not it enabled by default (they don't even enable nfc pairing byy default FWIW), but just have it cleared with the distros. The last time there was a bluez DS3 problem, in fact, they fixed it in 4 days. And the staple of the community "sony guy" is also the one of the proposal, you know. As for RPCS3, it has been supporting pressure-sensitive buttons straight through HIDAPI since 5 years by now. And SDL too since version 2.26. If it wasn't that I believe analog keyboards are some kind of worthy generalizable use case, I might have as well called it a day on this.
> You should touch some grass I think? And you should get shit out of your head & eyes to see that it's not Twitter or Reddit. Also, if that's a question then the answer is: no, you did not think. > As can be read from the cover letter that added its support, the special > plugin just exists to provide automatic bluetooth address pairing over *USB* It "just" exist so it would be usable on Linux in wireless mode at all. Without it, it will not connect to host, as it needs to have host's MAC address hardcoded into it via USB. > The last time there was a bluez DS3 problem, in fact, they fixed it in 4 > days. Bluez fixing a problem will not help you if your distro removed DS3's wireless support completely. Unless you're a big fan of running some custom utility to manually write in your BT chip's MAC which casual users aren't. The patch you've originally linked was approved by a SUSE guy in 2017, yet SUSE still has not enabled bluez support in 2024. Recently DS3 plugin has even been refactored into core codebase but SUSE still fails to ship it due to some weird halt on updating bluez for half a year even in the bleeding edge rolling release repositories. Don't try to insult me as if it's not an example of farcically comedic corporate bureaucracy. > And the staple of the community "sony guy" is also the one of the proposal, > you know. No, I do not "know". "The proposals" came years early, at least since 2012, maybe even 2008. I do not know "the staple" of what community he supposed to be but I do know that before his proposal of "We felt it is best to remove [analogue support]" (who are "we"?), DS3 only had problem with few buttons for which there were unapproved patches. But instead of approving those, the whole thing got stripped away. For entire lifetime of PS3 Sony has ignored not just Linux but also Windows support. Only when PS3 was deemed obsoleted by PS4 that "official support" came in form of removing features, that were not present in DS4, instead of finishing the community patches for its completion. Again, refactoring of this obsoleted kernel API has been in Purgatory of Circular Sophistry at least since 2012, maybe even earlies, and here in 2024 all we have is still same gimped DS3 non-support from 2017. From what I vaguely remember, before that there was the issue only with wrong/missing events from few buttons which was fixed by some unapproved quick & dirty patch, after - no events, so "no issues". More than a decade of talking in circles and rejecting obvious solutions for not being "good enough". Again, textbook example of farcically comedic corporate bureaucracy. Hence the comparison to Wayland which is still, after 15 years, has no feature advantage but plenty of broken basic features in comparison to X11 which was also similarly intentionally gimped by removal of automatic precise DPI-based scaling and global hotkey activation on release, 2 major usability features unavailable on Wayland by design. > As for RPCS3, it has been supporting pressure-sensitive buttons straight > through HIDAPI since 5 years by now. And SDL too since version 2.26. > If it wasn't that I believe analog keyboards are some kind of worthy > generalizable use case, I might have as well called it a day on this. And PCSX2 probably had PS2's pressure sensitivity emulation via DS3 supported for 15+ years now. Self-contradicting much? I don't see how kernel not supporting passing data to userspace that expects it for years is justification for "called it a day on this". Or for belligerent provocations.
The first rule on this website is that you don't complain about distribution's own problems.. Putting even aside that SUSE has been enabling that switch since 15.0. Evdev obviously as is, is unfit to supporting n analog axes. And you are blind if you haven't realized you are talking about the same literal person pointing this fact out, and also bringing forward the proposal for improvements. Pcsx2 never supported pressure on linux until late 2022 with the aforementioned SDL change too. Stop digressions.