From: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-input@vger.kernel.org
Subject: Re: [PATCH 2/3] HID: steam: add serial number information.
Date: Fri, 16 Feb 2018 21:59:39 +0100 [thread overview]
Message-ID: <20180216205939.GA17329@casa> (raw)
In-Reply-To: <CAO-hwJ+9Jvd8x5dRaerstzeNNgY4_mUar77BB1k2ctxaOCJLtQ@mail.gmail.com>
On Fri, Feb 16, 2018 at 11:38:11AM +0100, Benjamin Tissoires wrote:
> On Fri, Feb 16, 2018 at 10:57 AM, Rodrigo Rivas Costa
> <rodrigorivascosta@gmail.com> wrote:
> > On Fri, Feb 16, 2018 at 10:31:35AM +0100, Benjamin Tissoires wrote:
> >> > Ok, I'll do that. The weird thing, however, is that:
> >> >
> >> > hid_hw_raw_request(steam->hid_dev, 0x00,
> >> > buf, hid_report_len(r), /* 64 */
> >> > HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
> >> >
> >> > fails with EOVERFLOW. I have to use:
> >> >
> >> > hid_hw_raw_request(steam->hid_dev, 0x00,
> >> > buf, 65
> >> > HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
> >> >
> >> > which just feels wrong to me.
> >>
> >> Indeed
> >>
>
> Arf, looks like usbhid expects the buffer to start with 0x00 when the
> report is not numbered, thus adding one to the report length.
>
> I guess that nobody tried to recently set/get reports on a device
> without a report ID. And hidraw matches this behavior too, which means
> it's hard to change.
>
> One thing I'd like to try to change is the result of hid_report_len.
> If everybody expects the size to be of one more when the report is
> unnumbered, maybe we could simply add this placeholder in the report
> size from the beginning.
I've been trying to make sense of all this numbered/buf++/count-- stuff,
and I admit I don't understand half of it...
But about that +7 in hid_alloc_report_buf(), isn't it to make room for
the implement()/extract() functions? And IIUIC those are not used for
raw_requests... they are instead passed directly to usb_control_msg()
(or whatever the ll driver does). That's the point of being raw, isn't
it?
If I'm right with that, would it make sense to go back to kzalloc(65)?
If I'm wrong, then if you agree, I'll default to:
hid_hw_raw_request(steam->hid_dev, 0x00,
buf, hid_report_len(r) + 1, /* count the request number */
HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
Then, if hid_report_len() is ever updated to return the +1, this one
should be removed. And even if it is not, we still have +6 extra bytes
from hid_alloc_report_buf(), so no real harm done.
Regards.
Rodrigo
next prev parent reply other threads:[~2018-02-16 20:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 12:03 [PATCH 1/3] HID: add driver for Valve Steam Controller Rodrigo Rivas Costa
2018-02-13 12:03 ` [PATCH 2/3] HID: steam: add serial number information Rodrigo Rivas Costa
2018-02-14 14:51 ` Benjamin Tissoires
2018-02-15 22:16 ` Rodrigo Rivas Costa
2018-02-16 8:44 ` Benjamin Tissoires
2018-02-16 9:02 ` Rodrigo Rivas Costa
2018-02-16 9:31 ` Benjamin Tissoires
2018-02-16 9:57 ` Rodrigo Rivas Costa
2018-02-16 10:38 ` Benjamin Tissoires
2018-02-16 20:59 ` Rodrigo Rivas Costa [this message]
2018-02-13 12:03 ` [PATCH 3/3] HID: steam: add battery device Rodrigo Rivas Costa
2018-02-14 14:54 ` Benjamin Tissoires
2018-02-14 14:45 ` [PATCH 1/3] HID: add driver for Valve Steam Controller Benjamin Tissoires
2018-02-14 21:28 ` Philippe Ombredanne
2018-02-14 23:29 ` Rodrigo Rivas Costa
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=20180216205939.GA17329@casa \
--to=rodrigorivascosta@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).