linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Roderick Colenbrander <thunderbird2k@gmail.com>,
	Martyn Welch <martyn@welchs.me.uk>,
	linux-input <linux-input@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"Conn O'Griofa" <connogriofa@gmail.com>,
	"Colenbrander, Roelof" <roderick.colenbrander@sony.com>
Subject: Re: [PATCH] HID: Sony: Add support for Gasia controllers
Date: Thu, 6 Feb 2020 09:09:53 +0100	[thread overview]
Message-ID: <CAO-hwJJk411hGTJ6uSdzAFCzf1WJehhifdN0r5kMG6aqL=dnpw@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.2002031218230.26888@cbobk.fhfr.pm>

Hi,

On Mon, Feb 3, 2020 at 12:23 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Mon, 3 Feb 2020, Benjamin Tissoires wrote:
>
> > I am definitely not in favour of that :(
> >
> > The basic problem we have here is that some vendors are overriding your
> > VID/PIDs, and this is nasty. And I do not see any reasons why you can't
> > say: "well, we broke it, sorry, but we only support *our* devices, not
> > third party ones".
>
> Well, it's not about "we broke it" in the first place, as far as I
> can tell.
>
> Roderick's concern is that 3rd party devices with overriden VID/PID
> malfunction for completely unrelated reason to (correctly working) changes
> done in favor of stock Sony devices, but it'll be Sony receiving all the
> reports/blame.

After re-reading the code, I am not sure we can easily detect the
clones. So at some point, I think we will break them, but there is not
much we can do. I don't really have a solution for that :(

>
> > One thing that comes to my mind (probably not the best solution), is to
> > taint the kernel if you are facing a non genuine product. We do that for
> > nvidia, and basically, we can say: "well, supporting the nvidia blob is
> > done on a best effort case, and see with them directly if you have an
> > issue". Tainting the kernel is a little bit rough, but maybe adding an
> > info message in the dmesg if you detect one of those can lead to a
> > situation were we can count on you for supporting the official products,
> > and you can get community support for the clones.
>
> Yeah; which I wouldn't like to do for upstream kernel, but Sony could
> definitely do this for the products they ship.
>
> The same way distros are tainting their kernels when unsupported modules
> (but otherwise perfectly fine wrt. GPL and everything else) are loaded
> into distro-supported kernels.
>
> > One last thing. Roderick, I am not sure if I mentioned that or not, but
> > I am heavily adding regression tests for HID in
> > https://gitlab.freedesktop.org/libevdev/hid-tools/
>
> ... and words can't express how thankful I am for that :)
>

OK, I played with that idea earlier this week:
https://gitlab.freedesktop.org/libevdev/hid-tools/merge_requests/74
I only have a Sixaxis controller, and I only implemented the USB part
of it (AFAICT).
Currently this ensures the button mapping is correct, and that the
LEDs are working properly.
We are still missing a few bits and pieces, but the initialization
(requests made by the kernel to start the device and press on the PS
button) is handled properly.

If this is something Roderick would be interested in, we can then try
to extend this initial work on Bluetooth controllers and the DualShock
ones.
Adding the clones ones based on the current kernel code is something
doable, but I do not expect Sony to be involved in that process.

That being said, before we merge this particular patch about Gasia
controllers, now we need to implement a regression test first :)

Cheers,
Benjamin


  reply	other threads:[~2020-02-06  8:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-26 19:45 [PATCH] HID: Sony: Add support for Gasia controllers Martyn Welch
2020-01-27 22:07 ` Roderick Colenbrander
2020-01-28 10:11   ` Jiri Kosina
2020-01-29  6:08     ` Roderick Colenbrander
2020-01-28 18:47   ` Martyn Welch
2020-01-29  6:22     ` Roderick Colenbrander
2020-02-03 10:02       ` Jiri Kosina
2020-02-03 10:48         ` Benjamin Tissoires
2020-02-03 11:22           ` Jiri Kosina
2020-02-06  8:09             ` Benjamin Tissoires [this message]
2020-02-06  9:34               ` Bastien Nocera
2020-02-09  5:04                 ` Roderick Colenbrander
2020-02-06 15:30               ` Roderick Colenbrander
2020-02-06 17:45                 ` Benjamin Tissoires
2020-02-06  9:14       ` Bastien Nocera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO-hwJJk411hGTJ6uSdzAFCzf1WJehhifdN0r5kMG6aqL=dnpw@mail.gmail.com' \
    --to=benjamin.tissoires@redhat.com \
    --cc=connogriofa@gmail.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martyn@welchs.me.uk \
    --cc=roderick.colenbrander@sony.com \
    --cc=thunderbird2k@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).