Re: [PATCH v2] Input: Add missing event codes for common IR remote buttons

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > 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.
>
> No, we will not be renaming this key. We try to have parity with the
> HUT, which has the following to say:
>
> "Aspect OSC - Selects the next available supported aspect ratio option
> on a device which outputs or displays video.  For example, common
> aspect ratio options are 4:3 (standard definition), 16:9 (often used
> to stretch a standard definition source signal to a 16:9 video screen),
> letter-box and anamorphic widescreen.The order in which the aspect
> ratios are selected is implementation specific."

Hi Dmitry,

The suggestion to rename KEY_ASPECT_RATIO was a `last resort` in the
event people are against a more suitable and accurate key to what
happens to the actual content. The root issue is in not making any
distinction between content AR, frame AR, and display AR. As
previously described, letterbox/pillarbox/windowbox is used to
*maintain* the correct AR, not alter it. Stretching may or may not
alter AR, zooming may or may not alter AR. There are more scenarios
where AR is unaffected than otherwise so more often KEY_ASPECT_RATIO
makes no sense than does. However, in all cases (except where content
& display match and you wouldn't use this key) how the frames are
being displayed *is* altered, which is where KEY_DISPLAY_FORMAT comes
from.

Best regards,
Derek



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux