

Issue is, not only do do my emulators not recognize these buttons, but is seems Linux Mint doesn’t know they exist at all. Even bringing up a program to map buttons to keys doesn’t show any input when those buttons are pressed.
Generally, USB HID permits lots of buttons to be reported. While I can’t say that it’s absolutely certain that 8bitdo requires some sort of proprietary protocol to expose the button events for some of those buttons, my bet is that they’re reporting them.
I don’t know what program you’re using, but there are at least three APIs that I can think of that they might be using.
-
(Old) Linux joystick API.
jstest /dev/input/js0to see what’s going on there (assuming a single game controller on the system). In thejoystickpackage on Debian. I have seen systems before that have this disabled to try to deal with programs that double-report button events for joysticks visible both under the joystick API and the libevent one. -
(New) event API.
$ evtest. All of your other stuff, like mice and keyboards, will also be visible here, and you’ll have to tellevtestwhich device you want to see events from. In theevtestpackage on Debian. -
Steam has its own input API, Steam Input. Steam Input will internally be using one of the above, but it could be fiddling with things, like, not sending button events or something, and a lot of games on Linux under Steam will be using Steam Input.
There are also other (thinner) libraries that will map one of the two kernel APIs to their own API, like SDL. Couldn’t advise what your emulator might be using without knowing what emulator you’re trying to use.
I also have an old Logitech F710 around here somewhere that has a switch on it to cause the controller to report (on Windows) via (old Windows) DirectX or (old Windows) XInput. In the DirectX mode, it doesn’t report as much information. Probably not what you’re seeing, but thought I’d mention it as a possibility.





















Yeah, then that restriction isn’t the problem. Sorry; I guessed wrong.
It won’t help here, but for future reference, what you likely did is this:
sudoruns a command as root. The file redirection, however, is done by the current shell, which isn’t run as root, not byecho. Soecho 0is run as root, and then bash tries to open /proc/blah/whatever and doesn’t have permission to do so, and that’s what fails.If you need to do this in the future, you can do this:
It might be okay to hit that, as I don’t know if scanmem avoids trying to scan all regions that it can’t read. That does mean that it is able to ptrace() it and find some matches. Did you try to keep going with additional searches to see if it could actually find the value and change it?