On 7/17/24 09:26, Roderick Colenbrander wrote:
If not, then maybe there is protocol documentation that could help
test writers in creating more precise tests?
Unfortunately none of the documentation for our controllers is
public. Just read between the lines in the code, which we cover with
some clues here and there :)
I've seen the clues and they are certainly an improvement of
hid-playstation over hid-sony that I am grateful for :)
As for the documentation, I didn't mean that you should open it to the
wide public (although that would be fabulous!). Rather, I suggested
providing what's needed to the people writing the downstream tests that
we've been going on about for a while now.
The utility of tests is... rather limited, if they don't verify an
actual specification, but just a specific code's behaviour. After all,
these tests would fail even when talking to a real PlayStation 4.
(The official Android tests are kind of kernel version agnostic
as they work across multiple kernel and Android versions.
Hm, sounds to me like the Android test framework is broken if it
cannot be kernel-specific in such cases. What's required in order
to improve this?
It is a bit of a long process we work on with Google. Some initial
fixing of some of the bugs will be for this year to make sure the 6.6
tests pass properly. But any work to maybe handle multiple behaviors,
that's quite tricky and would take quite a bit of time to be honest.
Sure, time is not the issue, as long as there is a clear light of
correct software at the end of the tunnel :)
Are these tests open source?
Can kernel patchers run the tests easily (without installing a full
Android SDK) and see which tests their patches would break?
Considering how widely Android and all these devices are used, I'm
hesitant to make changes to not cause regressions. Even just a simple
one can take forever to trickle down.
Apologies, I am still confused.
With v6.2, hid-playstation gained DS4 support. With v6.3, hid-sony lost
DS4 support.
DS4 support was removed from hid-sony just one minor release after it
was included in hid-playstation. I didn't see any hesitation there,
despite the wire protocol seeing significant changes compared to
hid-sony, which had been deployed for almost a decade.
Given how quickly the DS4 code was removed from hid-sony, why are fixes
suddenly difficult, less than two years into the hid-playstation era,
after around 8 years of DS4 support in hid-sony?
The change from hid-sony to hid-playstation caused a regression on a
real-world device, on Android phones:
I have an 8BitDo controller that quirkily emulates a DS4, and which
worked fine with my old Android phone, with a kernel from the hid-sony
days. With v6.3, this controller broke, and this went into LTS v6.6.
Does this kind of regression, which has clearly spread across the
Android ecosystem with v6.6, deserve to be fixed?
As a generalised question, how about controllers that work on Android
phones with kernel v6.1 (hid-sony), but not with v6.6 (hid-playstation),
because of protocol changes that don't affect first-party controllers.
Do we accept upstream regressions on actual, physical devices for the
sake of passing downstream tests?
Max
