From: Daniel Nguyen <daniel.nguyen.1@ens.etsmtl.ca>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Pascal Giard <pascal.giard@etsmtl.ca>,
"Colenbrander, Roelof" <Roderick.Colenbrander@sony.com>,
Jiri Kosina <jikos@kernel.org>,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>
Subject: Re: [PATCH] HID: sony: support for the ghlive ps4 dongles
Date: Fri, 23 Jul 2021 15:07:11 -0400 [thread overview]
Message-ID: <CAEJV-FEuxftWiDMjoqFniV1oRZLvcAVh-5bKOdHv_S5uDSeVoA@mail.gmail.com> (raw)
In-Reply-To: <CAO-hwJKCFO2c2VR36zfmU34OfxbxRAfpkhdFTSD+V3WB7fv1Xw@mail.gmail.com>
Good day Benjamin,
On Wed, Jul 21, 2021 at 2:44 PM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> On Wed, Jul 21, 2021 at 8:15 PM Daniel Nguyen
> <daniel.nguyen.1@ens.etsmtl.ca> wrote:
> >
> > Hello Benjamin,
> >
> > On Wed, Jul 21, 2021 at 6:16 AM Benjamin Tissoires
> > <benjamin.tissoires@redhat.com> wrote:
> > >
> > > On Tue, Jul 20, 2021 at 4:33 PM Pascal Giard <pascal.giard@etsmtl.ca> wrote:
> > > >
> > > > Hi Benjamin,
> > > >
> > > > On Tue, Jul 20, 2021 at 7:39 AM Benjamin Tissoires
> > > > <benjamin.tissoires@redhat.com> wrote:
> > > > >
> > > > > Hi Daniel (and Pascal),
> > > > >
> > > > > [adding Roderick in Cc who is dealing with the Sony driver from Sony
> > > > > itself :) ]
> > > > >
> > > > >
> > > > > On Thu, Jul 15, 2021 at 9:58 PM Daniel Nguyen <daniel.nguyen.1@ens.etsmtl.ca> wrote:
> > > > > >
> > > > > > This commit adds support for the Guitar Hero Live PS4 dongles.
> > > > >
> > > > > I was about to ask you to add some regression tests to
> > > > > https://gitlab.freedesktop.org/libevdev/hid-tools/-/blob/master/tests/test_sony.py
> > > > >
> > > > > This would likely have avoided the previous patch that was required and
> > > > > cc-ed to stable.
> > > > >
> > > > > But after looking slightly at the patch, I realized that the Guitar Hero
> > > > > code uses direct USB calls, which is not something we can emulate at the
> > > > > hid-tools level.
> > > > >
> > > > > However, after a second look at the code, I think that this part of the
> > > > > code just reimplements its own HID SET_OUTPUT code, and that is
> > > > > something we can easily emulate.
> > > > >
> > > > > Could you check if the following patch is still working properly on a
> > > > > PS3 dongle? and if so, add your PS4 support on top?
> > > > >
> > > > [...]
> > > >
> > > > I wasn't aware that this was possible. Of course we will check whether
> > > > that works or not.
> > > >
> > > > > ---
> > > > > commit 10e14f105553d2bd88bc7748e87154c5a8131e9e
> > > > > Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > > Date: Tue Jul 20 11:44:10 2021 +0200
> > > > >
> > > > > HID: sony: GHL: do not use raw USB calls
> > > > >
> > > > > We can rely on HID to do the job for us.
> > > > > This simplifies the code and also allows to implement regression tests.
> > > > >
> > > > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > >
> > > > > diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> > > > > index b3722c51ec78..901f61d286e8 100644
> > > > > --- a/drivers/hid/hid-sony.c
> > > > > +++ b/drivers/hid/hid-sony.c
> > > > > @@ -37,7 +37,6 @@
> > > > > #include <linux/idr.h>
> > > > > #include <linux/input/mt.h>
> > > > > #include <linux/crc32.h>
> > > > > -#include <linux/usb.h>
> > > > > #include <linux/timer.h>
> > > > > #include <asm/unaligned.h>
> > > > >
> > > > > @@ -92,7 +91,7 @@
> > > > > * https://github.com/ghlre/GHLtarUtility/blob/master/PS3Guitar.cs
> > > > > * Note: The Wii U and PS3 dongles happen to share the same!
> > > > > */
> > > > > -static const u16 ghl_ps3wiiu_magic_value = 0x201;
> > > > > +static const u16 ghl_ps3wiiu_magic_report = 1;
> > > > > static const char ghl_ps3wiiu_magic_data[] = {
> > > > > 0x02, 0x08, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00
> > > > > };
> > > > > @@ -597,7 +596,6 @@ struct sony_sc {
> > > > > /* DS4 calibration data */
> > > > > struct ds4_calibration_data ds4_calib_data[6];
> > > > > /* GH Live */
> > > > > - struct urb *ghl_urb;
> > > > > struct timer_list ghl_poke_timer;
> > > > > };
> > > > >
> > > > > @@ -622,56 +620,29 @@ static inline void sony_schedule_work(struct sony_sc *sc,
> > > > > }
> > > > > }
> > > > >
> > > > > -static void ghl_magic_poke_cb(struct urb *urb)
> > > > > -{
> > > > > - struct sony_sc *sc = urb->context;
> > > > > -
> > > > > - if (urb->status < 0)
> > > > > - hid_err(sc->hdev, "URB transfer failed : %d", urb->status);
> > > > > -
> > > > > - mod_timer(&sc->ghl_poke_timer, jiffies + GHL_GUITAR_POKE_INTERVAL*HZ);
> > > > > -}
> > > > > -
> > > > > static void ghl_magic_poke(struct timer_list *t)
> > > > > {
> > > > > int ret;
> > > > > struct sony_sc *sc = from_timer(sc, t, ghl_poke_timer);
> > > > > + const int buf_size = ARRAY_SIZE(ghl_ps3wiiu_magic_data);
> > > > > + u8 *buf;
> > > > >
> > > > > - ret = usb_submit_urb(sc->ghl_urb, GFP_ATOMIC);
> > > > > - if (ret < 0)
> > > > > - hid_err(sc->hdev, "usb_submit_urb failed: %d", ret);
> > > > > -}
> > > > > -
> > > > > -static int ghl_init_urb(struct sony_sc *sc, struct usb_device *usbdev)
> > > > > -{
> > > > > - struct usb_ctrlrequest *cr;
> > > > > - u16 poke_size;
> > > > > - u8 *databuf;
> > > > > - unsigned int pipe;
> > > > > -
> > > > > - poke_size = ARRAY_SIZE(ghl_ps3wiiu_magic_data);
> > > > > - pipe = usb_sndctrlpipe(usbdev, 0);
> > > > > + buf = kmemdup(ghl_ps3wiiu_magic_data, buf_size, GFP_KERNEL);
> > > > > + if (!buf)
> > > > > + return;
> > > > >
> > > > > - cr = devm_kzalloc(&sc->hdev->dev, sizeof(*cr), GFP_ATOMIC);
> > > > > - if (cr == NULL)
> > > > > - return -ENOMEM;
> > > > > + ret = hid_hw_raw_request(sc->hdev, ghl_ps3wiiu_magic_report, buf,
> > > > > + buf_size,
> > > > > + HID_OUTPUT_REPORT, HID_REQ_SET_REPORT);
> > > > > + if (ret < 0) {
> > > > > + hid_err(sc->hdev, "can't poke ghl magic\n");
> > > > > + goto out;
> > > > > + }
> > > > >
> > > > > - databuf = devm_kzalloc(&sc->hdev->dev, poke_size, GFP_ATOMIC);
> > > > > - if (databuf == NULL)
> > > > > - return -ENOMEM;
> > > > > + mod_timer(&sc->ghl_poke_timer, jiffies + GHL_GUITAR_POKE_INTERVAL*HZ);
> > > > >
> > > > > - cr->bRequestType =
> > > > > - USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_OUT;
> > > > > - cr->bRequest = USB_REQ_SET_CONFIGURATION;
> > > > > - cr->wValue = cpu_to_le16(ghl_ps3wiiu_magic_value);
> > > > > - cr->wIndex = 0;
> > > > > - cr->wLength = cpu_to_le16(poke_size);
> > > > > - memcpy(databuf, ghl_ps3wiiu_magic_data, poke_size);
> > > > > - usb_fill_control_urb(
> > > > > - sc->ghl_urb, usbdev, pipe,
> > > > > - (unsigned char *) cr, databuf, poke_size,
> > > > > - ghl_magic_poke_cb, sc);
> > > > > - return 0;
> > > > > +out:
> > > > > + kfree(buf);
> > > > > }
> > > > >
> > > > > static int guitar_mapping(struct hid_device *hdev, struct hid_input *hi,
> > > > > @@ -2968,7 +2939,6 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > > > > int ret;
> > > > > unsigned long quirks = id->driver_data;
> > > > > struct sony_sc *sc;
> > > > > - struct usb_device *usbdev;
> > > > > unsigned int connect_mask = HID_CONNECT_DEFAULT;
> > > > >
> > > > > if (!strcmp(hdev->name, "FutureMax Dance Mat"))
> > > > > @@ -2988,7 +2958,6 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > > > > sc->quirks = quirks;
> > > > > hid_set_drvdata(hdev, sc);
> > > > > sc->hdev = hdev;
> > > > > - usbdev = to_usb_device(sc->hdev->dev.parent->parent);
> > > > >
> > > > > ret = hid_parse(hdev);
> > > > > if (ret) {
> > > > > @@ -3031,15 +3000,6 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > > > > }
> > > > >
> > > > > if (sc->quirks & GHL_GUITAR_PS3WIIU) {
> > > > > - sc->ghl_urb = usb_alloc_urb(0, GFP_ATOMIC);
> > > > > - if (!sc->ghl_urb)
> > > > > - return -ENOMEM;
> > > > > - ret = ghl_init_urb(sc, usbdev);
> > > > > - if (ret) {
> > > > > - hid_err(hdev, "error preparing URB\n");
> > > > > - return ret;
> > > > > - }
> > > > > -
> > > > > timer_setup(&sc->ghl_poke_timer, ghl_magic_poke, 0);
> > > > > mod_timer(&sc->ghl_poke_timer,
> > > > > jiffies + GHL_GUITAR_POKE_INTERVAL*HZ);
> > > > > @@ -3054,7 +3014,6 @@ static void sony_remove(struct hid_device *hdev)
> > > > >
> > > > > if (sc->quirks & GHL_GUITAR_PS3WIIU) {
> > > > > del_timer_sync(&sc->ghl_poke_timer);
> > > > > - usb_free_urb(sc->ghl_urb);
> > > > > }
> > > > >
> > > > > hid_hw_close(hdev);
> > > > > ---
> > > >
> > > > Was your patch against the master branch of hid/hid.git ?
> > >
> > > It was against the branch for-next of hid/hid.git, to account for the
> > > PS3 fix that was sent earlier.
> > >
> > > > I'm asking because it doesn't apply at all on my end, unless I use
> > > > --ignore-whitespace in which case, 3 out of 8 hunks fail.
> > > >
> > > > I assume I may be doing something wrong. I tried both downloading the
> > > > raw message from marc.info and from patchwork in case gmail would
> > > > mangle spaces/tabs, same result.
> > > >
> > > > Any idea?
> > >
> > > Usually opening the source of the email, and doing `git am -3`, hit
> > > enter, then paste the content of the patch, then Ctrl-D is the
> > > quickest you can do to apply such inlined patches (at least, that's
> > > what I do).
> > >
> > > But Daniel found out that the patch is buggy, so let's concentrate on
> > > the next iteration.
> >
> > I dove deeper into the proposed method and verified the functions in
> > order to better understand how they work. I noticed that the const that you
> > created (ghl_ps3wiiu_magic_report = 1) is modifying the first byte of the data
> > to 0x01. I also noticed that it is what creates the wValue = 0x201, which
> > explains why you set it to 1.
> >
> > After testing, I noticed that if we maintain the wValue = 0x201, and therefore
> > byte[0] = 0x01, the dongle does not function as it should. However, if we
> > change the const (ghl_ps3wiiu_magic_report = 2), although we have
> > wValue = 0x202, the dongle does function as expected. That's surprising
> > to us. Do you have any insights into the role of wValue in this context?
> > We came up with 0x201 as we were simply reproducing what
> > we had sniffed.
>
> The answer is in usbhid_set_raw_report()
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/usbhid/hid-core.c#n907)
>
> -> the wValue is used as `((rtype + 1) << 8) | reportnum`
>
> where rtype is the report type (declared in include/linux/hid.h)
> #define HID_INPUT_REPORT 0
> #define HID_OUTPUT_REPORT 1
> #define HID_FEATURE_REPORT 2
>
> And reportnum is the report number (the one matching the report ID if
> you look at the report descriptors.
>
> I am as much as puzzled as you regarding the fact that writing the urb
> directly works with '1' when it doesn't with the HID stack...
>
> Actually, the HID stack would overwrite the first byte with the report
> ID, which explains why the report gets changed.
>
> However, why was the initial call setting a HID report ID of 1 but
> then addressing the report 2??? That's probably a mystery we won't
> solve :)
>
> >
> > Despite the error message related to scheduling, I have not been able to
> > pinpoint the source of the hard freeze. Any hint there would be appreciated.
>
> I would have to think about this a little bit more, but I have been
> dragged all day with other internal work :(
>
> >
> > Lastly, I wanted to point out that for the PS4 dongle support, the
> > magic data is
> > not sent via control transfers, but through interrupt transfers. Does the HID
> > infrastructure have the necessary mechanisms to do that as well or will we
> > have to resort to the direct USB calls (like currently done in the patch
> > I submitted)?
>
> We have usbhid_output_report in this file, which can be genetically
> called via hid_hw_output_report()
>
> Also, IIRC it happens that sometimes a device would accept both
> interrupt or control transfers for these kind of methods. It might be
> interesting to see if you can not have a common path between the 2.
>
Following your insights, I tested whether the PS4 support could be performed
as a control transfer instead of interrupt. It can! However, the
inverse does not,
i.e., I tried using interrupt transfers instead of control transfers
for the PS3
dongle and it didn't work. I found this very interesting. Thank you for
mentioning it.
Besides, I looked into hid_hw_raw_request() and noted that it uses
usb_control_msg().
The documentation mentions the following about usb_control_msg():
"Don't use this
function from within an interrupt context. If you need an asynchronous message,
or need to send a message from within interrupt context, use usb_submit_urb()."
Looking at how hid_hw_raw_request() is often used, it is performed
during probe(),
before HID reports begin polling. In our case, we are attempting to schedule a
control transfer while the device is constantly polling for HID
reports. Therefore,
if I understand correctly, the likelihood of using usb_submit_urb()
(via hid_hw_raw_request()) within interrupt context is high. Thus, we should
not use hid_hw_raw_request(). Does this sound plausible?
I tried to find a function from within HID that uses usb_submit_urb() to
send a control transfer, but failed. Any insight?
Lastly, based on the experiments mentioned above, I could change the
PS4-dongle support to use control transfers instead of interrupt transfers,
therefore sharing more codepaths with the PS3-dongle support. Is that
something that would be appreciated?
Thank you,
-Daniel
prev parent reply other threads:[~2021-07-23 19:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-15 19:57 [PATCH] HID: sony: support for the ghlive ps4 dongles Daniel Nguyen
2021-07-20 11:36 ` Benjamin Tissoires
2021-07-20 14:33 ` Pascal Giard
2021-07-20 22:42 ` Nguyen, Daniel
2021-07-21 10:16 ` Benjamin Tissoires
2021-07-21 18:15 ` Daniel Nguyen
2021-07-21 18:44 ` Benjamin Tissoires
2021-07-23 19:07 ` Daniel Nguyen [this message]
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=CAEJV-FEuxftWiDMjoqFniV1oRZLvcAVh-5bKOdHv_S5uDSeVoA@mail.gmail.com \
--to=daniel.nguyen.1@ens.etsmtl.ca \
--cc=Roderick.Colenbrander@sony.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=pascal.giard@etsmtl.ca \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).