lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251119163844.1343-1-Hunter.Moore@garmin.com>
Date: Wed, 19 Nov 2025 10:38:42 -0600
From: Hunter Moore <Hunter.Moore@...min.com>
To: <dmitry.torokhov@...il.com>
CC: <Hunter.Moore@...min.com>, <linux-input@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: [PATCH] input: Add marine keycodes for radar control.

Hi Dmitry,

It may help if I provide some context of what we are intending on doing.
We are currently updating some of our radar capabilities. One of the goals
necessitates that our radar devices can be controlled by dedicated hardware
controls. You can see this requirement documented in this publicly available
IMO standards document, section 6.1.3[1].

We would like to create as open of a platform as possible to allow 3rd party
manufacturers to create radar control panels. The additional keys are industry
standard functions amoung other commonly available radar control panels, and
not specific to proprietary features. Since radars are important for user
awareness while navigating, we also want to ensure that 3rd party input is
clearly defined.

> No, we will not be adding these new keys since I do not see any users of
> the previously defined ones anywhere, not in kernel sources and not in
> the HID specification.

> You seem to be creating a purpose-built devices where you control your
> userspace, and I do not think the new keycodes will be of any use to
> anyone but your specific application.

We currently allow 3rd party input devices to use the previously defined keys
in our marine ecosystem. These inputs can come from physical user input
devices, networked input devices, or from other applications that run
alongside our application.

> You are also unlikely to be
> running anything else besides the software that you are developing on
> these devices, so I'd recommend simply reuse parts of the existing key
> code space for your purposes (KEY_MACRO*, BTN_TRIGGER_HAPPY*, etc).

The documentation currently states “The KEY_MACRO# codes MUST also NOT be used
as fallback for when no existing KEY_FOO define matches the marking / purpose.
In this case a new KEY_FOO define MUST be added“.

As such, we are apprehensive to repurpose the existing generic keys, for fear
of their purpose changing or unintended user behavior with 3rd party input
devices. If we are unable to get dedicated key codes added, do you have a
suggestion for how to correctly deal with this problem?

[1]: https://wwwcdn.imo.org/localresources/en/KnowledgeCentre/IndexofIMOResolutions/MSCResolutions/MSC.192(79).pdf


________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ