[PATCH] protocol: add set_scaling_filter request to wl_surface interface

[Pekka Paalanen]

On Thu, 2 Jan 2020 14:56:07 +0530
"Lattannavar, Sameer" <sameer.lattannavar at intel.com> wrote:

> 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.

Hi,

cool.

> > 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. 

Yes. The thing is, a (desktop) compositor must be able to switch
between hardware (KMS) and software (OpenGL) compositing on a frame by
frame basis. If these two methods produce noticeably different results,
the user is going to see the image changing "for no reason". In practise
compositors should reach a steady state fast and the change is very
often triggered by another intentional change which may hide the
glitch, but such flickering could still be annoying. Hence we try to
make the two as similar as possible.

That means it might not be possible to exercise all the scaling methods
a DRM driver exposes, but I suppose picking between NEAREST and LINEAR
should be enough to prove most of the new kernel UAPI. Those two
filtering methods are simple and well-known and already used in
Weston's GL-renderer, courtesy of the GL implementation.

> > 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.

Awesome, thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200109/c35031e3/attachment.sig>