All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
To: linux-input@vger.kernel.org, Geert Uytterhoeven <geert@glider.be>,
	linux-renesas-soc@vger.kernel.org
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Max Gurtovoy <mgurtovoy@nvidia.com>,
	Hans de Goede <hdegoede@redhat.com>, Wu Hao <hao.wu@intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Ertman <david.m.ertman@intel.com>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	Stephan Gerhold <stephan@gerhold.net>,
	Xu Yilun <yilun.xu@intel.com>,
	linux-kernel@vger.kernel.org (open list)
Subject: [PATCH v2] Input: add 'safe' user switch codes
Date: Fri,  5 Nov 2021 10:35:07 +0000	[thread overview]
Message-ID: <20211105103508.4153491-1-kieran.bingham+renesas@ideasonboard.com> (raw)

All existing SW input codes define an action which can be interpreted by
a user environment to adapt to the condition of the switch.

For example, switches to define the audio mute, will prevent audio
playback, and switches to indicate lid and covers being closed may
disable displays.

Many evaluation platforms provide switches which can be connected to the
input system but associating these to an action incorrectly could
provide inconsistent end user experiences due to unmarked switch
positions.

Define two custom user defined switches allowing hardware descriptions
to be created whereby the position of the switch is not interpreted as
any standard condition that will affect a user experience.

This allows wiring up custom generic switches in a way that will allow
them to be read and processed, without incurring undesired or otherwise
undocumented (by the hardware) 'default' behaviours.

Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
---

Sigh, a compile test might have at least saved the buildbots the trouble
of notifying me I also need to update the INPUT_DEVICE_ID_SW_MAX. But
even so - I'm really looking for a discussion on the best ways to
describe a non-defined switch in device tree.

Here's a compiling v2 ;-) But the real questions are :

 - Should an existing feature switch be used for generic switches?
 - Should we even have a 'user' defined switch?
 - If we add user switches, how many?


 include/linux/mod_devicetable.h        | 2 +-
 include/uapi/linux/input-event-codes.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index ae2e75d15b21..dfa1e4f41cd8 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -326,7 +326,7 @@ struct pcmcia_device_id {
 #define INPUT_DEVICE_ID_LED_MAX		0x0f
 #define INPUT_DEVICE_ID_SND_MAX		0x07
 #define INPUT_DEVICE_ID_FF_MAX		0x7f
-#define INPUT_DEVICE_ID_SW_MAX		0x10
+#define INPUT_DEVICE_ID_SW_MAX		0x12
 #define INPUT_DEVICE_ID_PROP_MAX	0x1f
 
 #define INPUT_DEVICE_ID_MATCH_BUS	1
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 225ec87d4f22..84a7b3debcb3 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -894,7 +894,9 @@
 #define SW_MUTE_DEVICE		0x0e  /* set = device disabled */
 #define SW_PEN_INSERTED		0x0f  /* set = pen inserted */
 #define SW_MACHINE_COVER	0x10  /* set = cover closed */
-#define SW_MAX			0x10
+#define SW_1			0x11  /* set = user defined */
+#define SW_2			0x12  /* set = user defined */
+#define SW_MAX			0x12
 #define SW_CNT			(SW_MAX+1)
 
 /*
-- 
2.30.2


             reply	other threads:[~2021-11-05 10:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05 10:35 Kieran Bingham [this message]
2021-11-05 17:00 ` [PATCH v2] Input: add 'safe' user switch codes Jeff LaBundy
2021-11-05 23:04   ` Dmitry Torokhov
2021-11-06 10:13     ` Kieran Bingham
2021-11-07  6:17       ` Jeff LaBundy
2021-11-08 11:00         ` Geert Uytterhoeven
2021-11-08 12:35           ` Kieran Bingham
2021-11-08 12:41             ` Geert Uytterhoeven

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=20211105103508.4153491-1-kieran.bingham+renesas@ideasonboard.com \
    --to=kieran.bingham+renesas@ideasonboard.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=david.m.ertman@intel.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=geert@glider.be \
    --cc=hao.wu@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=luzmaximilian@gmail.com \
    --cc=mgurtovoy@nvidia.com \
    --cc=stephan@gerhold.net \
    --cc=yilun.xu@intel.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.