Date:   Fri, 8 Apr 2022 20:38:51 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Shelby Heffron <Shelby.Heffron@...min.com>
Cc:     linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] input: Add Marine Navigation Keycodes

Hi Shelby,

On Thu, Mar 03, 2022 at 05:28:52PM -0600, Shelby Heffron wrote:
> Hi Dmitry,
> 
> We would like to take a step back and describe our application in more
> detail. We are supporting global physical keys on devices such as boat
> steering wheels that will interact with multiple marine navigation
> displays on the vessel. Could you please provide some further
> suggestions based on our requested keys and the description below.

Thank you very much for the detailed explanation.

> 
> Our marine displays usually show a single fullscreen application which
> may show multiple types of data at the same time. For example, the
> application may be showing a map, RADAR, and some media controls at the
> same time. There can also be a control bar at the bottom of the screen
> giving options to do things like return to the home page or open a menu.
> Multiple network-connected marine displays can interact with each other
> to share a single keyed input device across them. In this setup, there
> will only be one active focus for the set of those connected devices.
> For multi-display setups, the focus can transition between displays
> either through the use of dedicated keys to immediately move the focus
> to the previous or next display or the focus can transition between
> displays automatically (e.g. when the user requests to move the focus to
> the next element but we're already at the current display's last element
> we will move the focus to the first element of the next display).
> 
> For the elements displayed on a single marine display, our UI supports
> grouping them together into containers which function somewhat similarly
> to a group of radio buttons in a more-traditional application. We would
> place the previously mentioned map, RADAR, media controls, and bottom
> bar each into their own container. Containers also get used for things
> like menu pages where we have a list of items to scroll through and a
> separate list of buttons that can be used to take actions on the
> currently selected item. The focus can move between items within a
> container by using keys like up, down, left, right, next highlight, and
> previous highlight. To make navigating between these containers more
> convenient, we have a focus key that moves to the next container. This
> focus key behaves similarly to the tab key with a traditional
> application that has multiple sets of radio buttons, but we also have
> support for embedding traditional keyboard input into one of these
> containers where we would need KEY_TAB to behave normally. Our focus key
> does not change the visibility of anything on screen, which made it feel
> a little different than the description of KEY_CYCLEWINDOWS from the
> video remote controller documentation
> (https://www.kernel.org/doc/html/v4.9/media/uapi/rc/rc-tables.html), so
> our initial proposal avoided repurposing that event code.
> 
> >> +/* Toggle the focus in or out */
> >> +#define KEY_FOCUS_TOGGLE        0x27b
> >
> > Could it be served by KEY_SELECT?
> >
> 
> We have a select key on our marine display which is used for actions
> like to select/press the currently-focused button or behave similarly to
> a left mouse click when moving a cursor around on a map. We'd planned on
> using KEY_SELECT for that since its proximity to KEY_OK made us think it
> was intended to confirm selection of an item rather than to select the
> next item.
> 
> In our application, the focus key will move between containers on the
> same display, but we felt it was different than KEY_CYCLEWINDOWS or KEY_TAB.

I see. In HID spec we have consumer code 0x1A3 AL Next Task/Application
that seems to be fitting the bill. And we map it to KEY_NEXT (to which
you voicing the concerns below). But HID also defines

0xb5 Scan Next Track - Moves to the next chapter or track boundary
0xb6 Scan Previous Track - Moves to the previous chapter or track
boundary

that we map to KEY_NEXTSONG and KEY_PREVIOUSSONG and I recommend your
media application(s) to use those for media controls.

> 
> >> +/* Move between highlightable items */
> >> +#define KEY_NEXT_HIGHLIGHT        0x27c
> >> +#define KEY_PREVIOUS_HIGHLIGHT        0x27d
> >
> > I wonder if KEY_NEXT and KEY_PREVIOUS would be suitable for your
> > application.
> >
> 
> KEY_NEXT/KEY_PREVIOUS seemed to be designated as media-related to
> control chapters in the remote controller documentation, so our initial
> proposal avoided repurposing those event codes. We anticipate needing
> keys for next chapter/previous chapter to control our media inputs in
> the future, so using KEY_NEXT/KEY_PREVIOUS for highlight movement now
> could lead to conflicts for us down the road.
> 
> In our application, the next/previous highlight will transition the
> focus to elements within the same UI container.

OK, I see. Could we call them KEY_NEXT_ELEMENT/KEY_PREV_ELEMENT maybe?
And I would like to see comments describing intended use.

> 
> >> +/* Navigate Displays */
> >> +#define KEY_NEXT_DISPLAY        0x27f
> >> +#define KEY_PREVIOUS_DISPLAY        0x280
> >
> > I am not familiar with marine navigation devices, could you please
> > explain a bit more about displays you are navigating. Are there separate
> > physical screens or are there several application screens/views you are
> > switching between?
> >
> 
> Correct. These are separate physical screens. These keys would
> transition the current highlight between separate physical screens that
> are located next to each other.

OK, so we have the following keycodes:

KEY_SWITCHVIDEOMODE
KEY_VIDEO_NEXT
KEY_VIDEO_PREV

They are intended to request to switch between physical displays (see
drivers/acpi/acpi_video.c) and were introduced specifically for that in 
a7ecd1ea913346a72f41a002c365882dc05c9bd5.

The comments on KEY_VIDEO_NEXT and KEY_VIDEO_PREV are unfortunate, I'll
need to fix that, and their use in hid-input.c,
rc-terratec-cinergy-c-pci, and rc-tivo are not correct. I think,
however, that there are not a lot of systems where we have combination
of multiple signal sources, and multiple output displays, so probably
this clash does not matter in practice.

> 
> 
> >> +#define KEY_BRIGHTNESS_MENU        0x28c
> >
> > Do you have multiple menus in the application?
> >
> 
> Our marine displays do have multiple menus. This physical key will bring
> up a menu to immediately adjust the display brightness. Our displays go
> extremely bright and extremely dim to support outdoor use during the day
> or at night. This physical key can be used to quickly adjust brightness.

OK, then we shall have it.

Thanks.

-- 
Dmitry

Powered by blists - more mailing lists