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
