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. 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. >> +/* 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. >> +/* 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. >> +#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. Thank you for your assistance. ________________________________ 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.
