[PATCH] protocol: add set_scaling_filter request to wl_surface interface

[Lattannavar, Sameer]

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>
> >  
> 
> Hi,
> 
> 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
for scaling. 

> 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
repositories.
> 
> Thanks,
> pq