From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Luke Jones <luke@ljones.dev>,
linux-input <linux-input@vger.kernel.org>,
Jiri Kosina <jikos@kernel.org>,
Andy Shevchenko <andy@infradead.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>
Subject: Re: [PATCH V8] HID: ASUS: Add support for ASUS N-Key keyboard
Date: Mon, 19 Oct 2020 14:11:32 +0300 [thread overview]
Message-ID: <CAHp75VdUipcuHaapttW05n+C5Txw0AS9xstoeLKbiqsKxx14Kg@mail.gmail.com> (raw)
In-Reply-To: <b95839dc-82eb-7413-9000-17939f21b35b@redhat.com>
On Mon, Oct 19, 2020 at 12:54 PM Hans de Goede <hdegoede@redhat.com> wrote:
> On 10/18/20 11:36 PM, Luke Jones wrote:
> >>> + if (report->id == FEATURE_KBD_LED_REPORT_ID1 ||
> >>> + report->id == FEATURE_KBD_LED_REPORT_ID2) {
> >>
> >>> + return -1;
> >>
> >> is -1 a good return code? (this Q for all cases)
> >>> + ret = asus_wmi_send_event(drvdata, 0xae);
> >>> + if (ret < 0) {
> >>> + hid_warn(hdev, "Asus failed to trigger fan control event");
> >>> + }
> >>
> >>> + return -1;
> >
> > In the case of this block I really don't have any idea how
> > to handle it. I want to stop these particular keycodes from
> > being evaluated elsewhere. Returning -1 seemed to be the only
> > way to do this, unless my understanding is very incorrect.
> >
> > Any help or guidance on how to handle this is definitely
> > appreciated.
>
> Sorry, I missed that Andy's comment on this where for the raw-event handler,
> in this case -1 has the special meaning of don't process this event further,
> rather then being an error code.
Good to know, thanks!
> So, since in this case -1 has a special meaning and it is NOT an error
> code, using -1 is fine. IOW you can keep this part as is.
I agree with Hans, you may ignore my question in those cases.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-10-19 11:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-13 7:35 [PATCH V8] HID: ASUS: Add support for ASUS N-Key keyboard Luke D Jones
2020-10-13 7:37 ` Luke Jones
2020-10-15 11:11 ` Andy Shevchenko
2020-10-18 21:23 ` Luke Jones
2020-10-18 21:36 ` Luke Jones
2020-10-19 9:54 ` Hans de Goede
2020-10-19 11:11 ` Andy Shevchenko [this message]
2020-10-16 10:51 ` Hans de Goede
2020-10-16 20:10 ` Luke Jones
2020-10-18 8:59 ` Hans de Goede
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=CAHp75VdUipcuHaapttW05n+C5Txw0AS9xstoeLKbiqsKxx14Kg@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=andy@infradead.org \
--cc=benjamin.tissoires@redhat.com \
--cc=hdegoede@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=luke@ljones.dev \
/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).