On Tue, 2019-01-22 at 23:50 -0800, VDR User wrote:
> > > KEY_SCREEN_INPUT is used to bring up things like an on-screen
> > > keyboard or other on-onscreen user input method.
> >
> > We already have KEY_ONSCREEN_KEYBOARD.
> >
> > > > > +#define KEY_SYSTEM_MENU 0x2ed /* Open
> > > > > systems menu/display */
> > > >
> > > > KEY_MENU?
> > >
> > > Systems menus as pertains to DVB. KEY_MENU is generic and having
> > > only
> > > one `menu` option is problematic when you have different types of
> > > menus which aren't accessible from each other.
> >
> > We have KEY_MENU/KEY_CONTEXT_MENU/KEY_ROOT_MENU/KEY_MEDIA_TOP_MENU.
> > Are you sure we need another one?
>
> There are multiple MENU keys I assume for clarity purposes and to
> give
> some kind of relation between the key definition and the action/event
> that occurs when you use it. I would say it's more a matter of
> convenience rather that need, similar to KEY_ROOT_MENU &
> KEY_MEDIA_TOP_MENU; It's not a necessity that these two exist, but
> they do out of convenience. You could still make things work if one
> of
> them vanished.
Those 2 keys were added because they were present on DVD player remotes
nearly 20 years ago ("Root menu" vs. "Top Menu"), and do different
things.
Dmitry, the difference between:
#define KEY_MENU 139 /* Menu (show menu) */
and:
#define KEY_CONTEXT_MENU 0x1b6 /* GenDesc - system context
menu */
isn't super clear to me. The first one is used for contextual menu on
keyboards (the menu key added since Windows 95), does KEY_CONTEXT_MENU
do the same thing?
> > > > > +#define KEY_SERVICES 0x2ee /* Access
> > > > > services */
> > > > > +#define KEY_DISPLAY_FORMAT 0x2ef /* Cycle
> > > > > display formats */
> > > >
> > > > KEY_CONTEXT_MENU?
> > >
> > > KEY_DISPLAY_FORMAT doesn't open any menus and is used to cycle
> > > through
> > > how video is displayed on-screen to the user; full, zoomed,
> > > letterboxed, stretched, etc. KEY_CONTEXT_MENU would be for
> > > something
> > > like bringing up a playback menu where you'd set things like
> > > upscaling, deinterlacing, audio mixdown/mixup, etc.
> >
> > KEY_ASPECT_RATIO (formerly KEY_SCREEN).
>
> Physical displays have a single set aspect ratio (W/H). Images have
> their own aspect ratios. When the AR of the video to be display and
> the display itself are mismatched, you have to do something
> (letterbox, pillarbox, windowbox) to the video to maintain the
> correct
> video aspect ratio. You can't change the displays AR, and you aren't
> changing the videos AR so using KEY_ASPECT_RATIO makes no sense. AR
> isn't being touched/altered/manipulated, but how the video is being
> displayed is. Stretching and filling to match the display AR alters
> the video AR so there is makes sense, but then zooming may not. So,
> since "aspect ratio" kind of makes sense in a couple cases, and makes
> no sense in the rest, the more suitable KEY_DISPLAY_FORMAT is my
> suggestion.
The "Aspect Ratio" or "Ratio" key on loads of remotes have been doing
this exact thing since the days of the first 16:9/cinema displays. I
really don't think you need a new key here.
