linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Luke Jones <luke@ljones.dev>,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: 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 11:54:30 +0200	[thread overview]
Message-ID: <b95839dc-82eb-7413-9000-17939f21b35b@redhat.com> (raw)
In-Reply-To: <8P2FIQ.M2MLXE7M40153@ljones.dev>

Hi,

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)
>>
>>>  +               /* Additional report filtering */
>>>  +               } else if (report->id == FEATURE_KBD_REPORT_ID) {
>>>  +                       /* Fn+F5 "fan" symbol, trigger WMI event to toggle next mode */
>>>  +                       if (data[1] == 0xae) {
>>>  +                               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.

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.

Regards,

Hans


  reply	other threads:[~2020-10-19  9:54 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 [this message]
2020-10-19 11:11       ` Andy Shevchenko
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=b95839dc-82eb-7413-9000-17939f21b35b@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@infradead.org \
    --cc=benjamin.tissoires@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).