Axis range was previously calculated as max + abs(min), which relies on the assumption that
min will not exceed 0. For (min, max) values like (0, 255) or (-128, 127), which I assume to
be the most common cases, the range is correctly calculated as 255. However, given (20,
235), the range is erroneously calculated as 255, leading to axis values being normalized
incorrectly.
SDL already handles this case correctly. After changing the range calculation to max - min,
the axis values received from the evdev backend are practically identical to the values
received from the SDL backend.
This has no effect now, as we've never bumped the database version.
Instead, it adds future proofing, and makes moving between a future
version with a bump and master clean.
We shouldn't try to create folder names that contain characters
such as : or / since they are forbidden or have special meanings.
(No officially released disc uses such characters, though.)
Now that all inputs are corrected to zero-centered, we can use getFlat()
to ignore movements that are just noise.
This eliminates a lot of drift when the controller is at rest, notably
on the character select screen in Melee.
Android reports the same physical axis multiple times for analog
triggers, and this handles this case.
There are also some controllers with broken mappings (eg the analog
triggers on a PS4 DualShock 4). These axis don't center correctly.
There are also some controllers (again, the PS4) that send both a button
press and an axis movement. This ignores the buttons so we can use the
analog axis. Otherwise, since the button comes before the axis moves
far we would always take the button.
There has been a lot of confusion about what the CPU clock override
section does among users, and looking at it… I’m not surprised! It
doesn’t directly state which CPU clock rate is being overridden!
This small change adjusts the language to clarify that the emulated CPU
is being adjusted.
The main problem was that the volume of the mixer wasn't savestated.
The volume is typically 0 at the beginning of a game, so loading a
savestate at the beginning of a game would lead to silent DTK audio.
I also added savestating to StreamADPCM.cpp.
Nowadays that Dolphin detects regions of discs properly and doesn't
force programs with unknown regions (such as homebrew) into running
under a certain region, the "Force Console as NTSC-J" option is
practically useless for making anything run correctly. Enabling it
is however an easy way to totally break many non-Japanese games.
The earlier code always tried to use TitleDatabase for getting
title names, but that didn't work for disc-based games, because
there was no way to get the maker ID.
Unlike VEN, the endpoint is determined by the value at 8-12.
If it's non-zero, HID submits the request to the interrupt OUT
endpoint. Otherwise, the request is submitted to the IN endpoint.
This commit changes HIDv5 to keep track of endpoints (like IOS does)
and use them when submitting interrupt transfers.
This implements /dev/usb/hid v5, found in IOS57, IOS58 and IOS59.
This is an initial implementation that ignores some differences
with VEN because I lack understanding of what IOS is actually doing
sometimes. These are documented on the WiiBrew article:
https://wiibrew.org/wiki//dev/usb/hid_(v5)
One major difference that this implementation handles is about IDs.
It turns out Nintendo has decided to include the interface number in
the top byte of HIDv5 device IDs, unlike VEN -- even though everything
else about ioctl 1 is otherwise the same!
USBv5 IOS resource managers share most of their code. Some ioctls
are even completely the same! So let's separate the common code
from the VEN specific stuff to make HIDv5 easier to implement.
The descriptor copy code is not actually the same in HIDv4 and VEN,
so it did not make a lot of sense to put it in USB/Common.cpp.
Separate and move it to HIDv4 and VEN.
This cleanup is important because there are even more differences
between HIDv4 and HIDv5.
Fix the device ID struct to reflect the actual structure used by IOS.
It turns out that offset 2 is the internal device index. The reason
that field seemed to be "0x1e - interface_number" is that IOS only
keeps track of 32 devices and always looks for free entries from
the end of the internal array. With each USB interface being exposed
as a separate USBv5 device, "0x1e - interface_number" was mostly
correct... but wrong!
We also made the assumption that the interface number can be
identified from just a USBV5 device ID, which is definitely not true.
VEN (and HID) keep track of the interface number in the internal struct
instead of "reconstructing" it from the device ID (which is normally
not possible if we were generating IDs correctly)
This commit fixes all of these inaccuracies.
