All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Ospite <ao2@ao2.it>
To: Mikko Perttunen <mikko.perttunen@kapsi.fi>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	jikos@kernel.org, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Mikko Perttunen <mperttunen@nvidia.com>
Subject: Re: [PATCH] HID: sony: disable descriptor fixup for FutureMax Dance Mat
Date: Thu, 21 Jul 2016 18:34:39 +0200	[thread overview]
Message-ID: <20160721183439.3edddbc6312555afda517f8c@ao2.it> (raw)
In-Reply-To: <78cafd15-850f-3110-f63e-bb41f6b69c5c@kapsi.fi>

On Tue, 19 Jul 2016 09:08:27 +0300
Mikko Perttunen <mikko.perttunen@kapsi.fi> wrote:

> On 07/18/16 17:28, Benjamin Tissoires wrote:
[...]
> >
> > Also, I think it would be better to have a check on the existing report
> > descriptor instead of blindly fixing it. Other drivers make sure they
> > are fixing the correct region before overriding it, but I think using a
> > md5sum might be just easier (though that's not required for your patch I
> > think).
> 
> I agree. In fact, the mat used to work back in 3.15 when the driver did 
> some rudimentary checks before overwriting the descriptor. In any case, 
> it would be difficult for me to add the checks since the mat is the only 
> piece of hardware I own that is handled by this driver.
> 

The fact that the report gets fixed up unconditionally is from
commit c607fb8 (HID: sony: Always override the Sixaxis descriptor).

The rationale behind this change was that compatible devices are
supposed to send exactly the same _raw_ data as the original ones, so
overriding the _whole_ descriptor unconditionally should keep them
working.

I would be interesting to understand why some (supposedly) compatible
devices break, maybe they rely on the fact that the PS3 would use the
original report?

BTW I'd slightly prefer the current way of having a straight path for
the common case (original and actually compatible devices) and handle
the exceptions explicitly using quirks, but I am open to changes and I
can test patches with some original controllers if needed.

Ciao ciao,
   Antonio

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

  reply	other threads:[~2016-07-21 16:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-17 17:25 [PATCH] HID: sony: disable descriptor fixup for FutureMax Dance Mat Mikko Perttunen
2016-07-18 14:28 ` Benjamin Tissoires
2016-07-19  6:08   ` Mikko Perttunen
2016-07-21 16:34     ` Antonio Ospite [this message]
2016-07-25  9:14       ` Benjamin Tissoires
2016-07-25 11:05         ` Antonio Ospite
2016-07-25 15:23           ` Mikko Perttunen
2016-07-25 15:25             ` Mikko Perttunen

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=20160721183439.3edddbc6312555afda517f8c@ao2.it \
    --to=ao2@ao2.it \
    --cc=benjamin.tissoires@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikko.perttunen@kapsi.fi \
    --cc=mperttunen@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.