Message-ID: <afda41dc-7b36-4ddd-abfc-c9430d8c9503@enpas.org>
Date: Thu, 11 Jul 2024 00:35:16 +0900
From: Max Staudt <max@...as.org>
To: Roderick Colenbrander <thunderbird2k@...il.com>
Cc: Roderick Colenbrander <roderick.colenbrander@...y.com>,
 Jiri Kosina <jikos@...nel.org>,
 Benjamin Tissoires <benjamin.tissoires@...hat.com>,
 linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] hid-playstation: DS4: Update rumble and lightbar
 together

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

Powered by blists - more mailing lists