linux-kernel - Re: [PATCH v1] hid-playstation: DS4: Update rumble and lightbar together

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEc3jaDzvus5ZDCupDzpy1HWRAwaKHQZLpDU4gO1=jTmPUzeKA@mail.gmail.com>
Date: Thu, 8 Aug 2024 16:11:34 -0700
From: Roderick Colenbrander <thunderbird2k@...il.com>
To: Max Staudt <max@...as.org>
Cc: Benjamin Tissoires <bentiss@...nel.org>, Jiri Kosina <jikos@...nel.org>, 
	Benjamin Tissoires <benjamin.tissoires@...hat.com>, 
	Roderick Colenbrander <roderick.colenbrander@...y.com>, linux-input@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] hid-playstation: DS4: Update rumble and lightbar together

On Mon, Jul 22, 2024 at 12:31 PM Max Staudt <max@...as.org> wrote:
>
> On 7/23/24 01:49, Benjamin Tissoires wrote:
> > Is there anyway to detect that the device can not support the current
> > behavior? And if so then dynamically switch to the new behaviour?
>
> Sadly, no, otherwise I would have used that already :(
>
>
> Also, the change that my patch makes is in the "dialect" of the wire
> protocol. This seemingly changes zero in the original Sony device's
> behaviour, both from what my tests have shown, and from what I gather
> from Roderick's emails. HID traces on the web confirm that the PS4 may
> output such or similar reports as well. Hence I don't understand why we
> would want to make a distinction at all, if the driver can simply only
> speak the "dialect" that works on most devices.
>
>
>
> Max
>

Sorry for my late reply. I just got back from vacation. Just catching
up on emails.

In general as Max also mentioned it is not a true regression as
various of these devices didn't work before. I have been thinking
about how to handle things. Preferably it would be some type of quirk.
Just changing the patterns is not a good idea also in case
hypothetically other features were get added (volume control for the
speaker, microphone settings,..) and other features which work through
the same output report and various of these devices probably won't
handle (or it is hard to predict).

I have been trying to think of ways to realize a quirk. I think we
need to search it in the HID reports. Either do some tests on reports
we know aren't supported (ugly). It can also be that the calibration
data is invalid (zeros, which we now initialize to a default). Or
perhaps is the firmware/hardware version related HID report returning
anything interesting?

Thanks,
Roderick