[PATCH] protocol: add set_scaling_filter request to wl_surface interface
sameer.lattannavar at intel.com
Thu Jan 2 09:26:07 UTC 2020
On Fri, Dec 20, 2019 at 09:51:54AM +0200, Pekka Paalanen wrote:
> On Fri, 20 Dec 2019 12:34:42 +0530
> Sameer Lattannavar <sameer.lattannavar at intel.com> wrote:
> > This is an extension for wl_surface interface to support
> > setting scaling filter. Client can request set_scaling_filter.
> > Protocol implementation posted at:
> > https://lists.freedesktop.org/archives/wayland-devel/2019-December/041098.html
> > Signed-off-by: Sameer Lattannavar <sameer.lattannavar at intel.com>
> > ---
> > protocol/wayland.xml | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index f1a13b7..3bb4df6 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1715,6 +1715,33 @@
> > <arg name="width" type="int" summary="width of damage rectangle"/>
> > <arg name="height" type="int" summary="height of damage rectangle"/>
> > </request>
> > +
> > + <request name="set_scaling_filter" since="3">
> > + <description summary="sets the filter to be used for scaling on a output">
> > + Blurry outputs during upscaling the video buffer, is a generic
> > + issue of graphics industry. One of the major reason behind this
> > + blurriness is the interpolation of pixel values used by most of the
> > + upscaling hardwares.
> > +
> > + Nearest-neighbor is a scaling_filter type, which works by filling in the
> > + missing color values in the upscaled image with that of the
> > + coordinate-mapped nearest source pixel value.
> > +
> > + Nearest-neighbor can produce (almost) non-blurry scaling outputs when
> > + the scaling ratio is complete integer. For example:
> > + - input buffer resolution: 1280x720(HD)
> > + - output buffer resolution: 3840x2160(UHD/4K)
> > + - scaling ratio (h) = 3840/1280 = 3
> > + - scaling ratio (v) = 2160/720 = 3
> > +
> > + In such scenarios, we should try to pick Nearest-neighbor as scaling
> > + method when possible.
> > + </description>
> > + <arg name="scaling_filter" type="int"
> > + summary="Positive scaling filter for interpretting type
> > + of filter to be used for integer scaling"/>
> > + </request>
> > +
> > </interface>
> why is this something that the client should be able to set?
I was under the assumption that based on client's request, I can enforce
filter selection in client itself.
> Why not have the compositor choose the method automatically based
> on e.g. content and output resolutions where it can take into
> account all the image processing, unlike a client ever could?
Agree, it makes sense to leave it to compositor.
> The compositor itself is already choosing the scaling methods for
> surfaces it decides or needs to scale itself (due to output scale,
> buffer scale, wp_viewporter, fractional scaling, etc.). Since KMS
> planes are just a compositor implementation detail of how to
> realize the composition, the compositor will want to use the same
> scaling method in KMS as it uses with its renderer (e.g. OpenGL).
AFAIU, here you provided details on HW(DRM) vs SW(GL) implementations
> Assuming the above questions are answered and the answers properly
> justified, this should be a new extension in wayland-protocols
> (like e.g. wp_viewporter is) and not on wl_surface in wayland.xml.
> We do not extend the wayland.xml interfaces unless it is absolutely
> necessary. We want to keep the fundamental protocol interfaces
> generic, simple and maintainable.
> Please also do all your Wayland, wayland-protocols, and Weston
> patch submissions in Gitlab as per the Contribution guidelines in
> each repository.
Thanks for pointing, I will submit patches in gitlab to the respective
More information about the wayland-devel