Hi Max, On Wed, Jul 10, 2024 at 8:35 AM Max Staudt <max@xxxxxxxxx> wrote: > > 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 :) Oh I see. Hm, we have been doing a lot of work in this space for both PS4 and PS5 controllers. We just didn't submit it yet and need to clean up the code a bit as we have some internal demand for this as well. We need to get our hands on some more of these controllers, validate before we were about to share the work. There are some details to these controllers (on the console it is kind of a separate driver even). > > 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? 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 :) > > > 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? 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. 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. > > > Max > > Roderick
