@@ -356,7 +356,11 @@ struct input_keymap_entry {
#define KEY_HELP 138 /* AL Integrated Help Center */
#define KEY_MENU 139 /* Menu (show menu) */
#define KEY_CALC 140 /* AL Calculator */
-#define KEY_SETUP 141
+#define KEY_SETUP 141 /* SC System Setup, i.e. enter BIOS-
+ level system (USB HID Usage Tables
+ 4.5.1). KEY_CONTROLPANEL makes more
+ sense for application- or operating
+ system-level configuration tasks. */
#define KEY_SLEEP 142 /* SC System Sleep */
#define KEY_WAKEUP 143 /* System Wake Up */
#define KEY_FILE 144 /* AL Local Machine Browser */
@@ -388,7 +392,14 @@ struct input_keymap_entry {
#define KEY_REWIND 168
#define KEY_PHONE 169 /* Media Select Telephone */
#define KEY_ISO 170
-#define KEY_CONFIG 171 /* AL Consumer Control Configuration */
+#define KEY_CONFIG 171 /* AL Consumer Control Configuration
+ (USB HID Usage Tables 15.15). Such
+ a tool should allow associating
+ keys/buttons with a consumer
+ device. KEY_CONTROLPANEL should be
+ assigned to keys that are intended
+ for more generic configuration
+ applications. */
#define KEY_HOMEPAGE 172 /* AC Home */
#define KEY_REFRESH 173 /* AC Refresh */
#define KEY_EXIT 174 /* AC Exit */
@@ -737,7 +748,12 @@ struct input_keymap_entry {
#define KEY_BUTTONCONFIG 0x240 /* AL Button Configuration */
#define KEY_TASKMANAGER 0x241 /* AL Task/Project Manager */
#define KEY_JOURNAL 0x242 /* AL Log/Journal/Timecard */
-#define KEY_CONTROLPANEL 0x243 /* AL Control Panel */
+#define KEY_CONTROLPANEL 0x243 /* AL Control Panel (USB HID
+ Usage Tables 15.15). Use
+ this instead of KEY_SETUP
+ for application- or
+ operating system- level
+ configuration tasks. */
#define KEY_APPSELECT 0x244 /* AL Select Task/Application */
#define KEY_SCREENSAVER 0x245 /* AL Screen Saver */
#define KEY_VOICECOMMAND 0x246 /* Listening Voice Command */
The KEY_* definitions in input.h had no formal functional definitions when they were first introduced. This led to a situation where some keys were used very inconsistently across different drivers. For example, KEY_SETUP was used both in some very low-level situations (like resetting the settings to the device defaults or to lauch some system backup tool for some integrated devices) and on high-level home media remote controls (where the key should open some kind of configuration window). To reach a more consistent usage of KEY_* definitions, it is crucial to add and extend comments in input.h to assign functional key definitions to KEY_* definitions, preferrably based on the USB HID Usage Tables for keys that are not defined in such a way yet. This patch adds such funtional definitions for KEY_SETUP, KEY_CONFIG and KEY_CONTROLPANEL. It further adds some information on how these definitions are related to each other. Signed-off-by: Hauke Pribnow <hauke.pribnow@gmx.net> --- (This is a re-submission because my e-mail client broke the patch by wrapping long lines. Sorry for that!) Hello everyone, first of all: I hope that I read enough about "The Process" so that I did not make any mistake in submitting this patch. This is my first Linux kernel patch ever - so please bear with me. Here's some more details that made me create this patch: I'm currently revising the keytable for a home media USB RF remote I own. During this process I got into contact with the original kernel driver module author who created the first keytable for this remote. He reviewed my proposed changes and agreed with most of my changes except of one: We ended up being confused about the meaning of the KEY_SETUP and KEY_CONFIG definitions in input.h. Since the input.h does not contain any information on what the functional definitions behind the KEY_* definitions are, I got into contact with the original author of the input.h file, Vojt?ch Pavlík, and asked for his opinion. He clarified that the KEY_* definitions had no formal definitions when they were first introduced. He concluded that it's basically about retro-defining what the keys mean. In my initial mail to him I proposed the definitions for KEY_SETUP and KEY_CONFIG like in the patch at hand to him. Fortunately he agreed in his reply that the reasoning behind my definitions makes sense. So I went ahead and created this first patch of two. Thanks a lot for any kind of feedback in advance, Hauke include/uapi/linux/input.h | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-)