Hi Roderick,
On 7/9/24 01:07, Roderick Colenbrander wrote:
The console behavior (I checked the code) does use the flags as well
like I do. The architecture there between usermode/kernel is a bit
different, so in some cases flags do get set when not needed.
Thank you so, so much for double checking this. It's always great to
have someone who can speak authoritatively on such matters and eliminate
the guesswork.
Various devices tried to capture bit patterns and see what kind of
worked even though not really right. (Officially licensed
controllers are a different story they use different hid reports.) We
didn't know other devices did this wrong.
Licensed controllers... That will be my next patch set, apologies in
advance :)
They need quite a few quirks, too... And as it turns out, my previous
patches have laid a lot of ground work for them :)
Correct the validation tests are all uhid based, which is the best
which can be done.
Please correct me if I'm getting the wrong idea here, but what I read
between the lines and from your email address is that this is something
in Sony's interest.
So an idea comes to mind: Maybe somewhere inside Sony, there exists
something like a DS4 simulator at the HID level, which could serve as a
foundation for improving the tests? That would get the tests much closer
to the gold standard, which is using a real controller.
If not, then maybe there is protocol documentation that could help test
writers in creating more precise tests?
There is the hid-tools one, but the one which we help out with, but
the key one is the Android ones. We have so many problems with these.
Mostly because of vendors not enabling e.g. FF support or LED support
other things.
Hm, but downstream users misconfiguring kernels is not our fault, is it?
In that case, the tests actually do their work correctly if they show
that something is amiss.
The main new Android kernel (public knowledge) is now 6.6 and many
new devices due later this year/early next year will use it. The
eco system is a lot wider now and the drivers are used a lot on
non-mobile devices (cars, televisions, chromecast,..). Occassionally
driver patches are also backported from upstream to older Android
kernels (patches have to be merged upstream first).
I see. But still, that is just typical downstream risk of building on
behaviour that the kernel does not provide guarantees for. I know
first-hand that backporting is a lot of work and easy to get wrong, but
this is the first time that I hear that as a reason to stop improving
the mainline kernel. Hence my confusion here.
Not that I wouldn't want these kind of patches, but I have to weigh
both sides.
Thanks for your understanding, and hence my offer to help if I somehow
can...
The pain on addressing things downstream and in Android conformance
tests is quite painful.
Hm, I can somewhat imagine this. I've heard that Android conformance is
quite strict.
Given Sony's supposed interest (see above), I guess it would be a
worthwhile investment to make the tests more robust? We could just hold
off on this patch for a while until downstream has better tests... What
would be a timeline for this to trickle downstream?
We would also have both code paths used in the wild forever, because
existing 6.6 devices wouldn't change behavior.
Well, that's kind of the point of LTS releases, if I'm not mistaken...
(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?
Max
