[PATCH 1/3] drm: Introduce scaling filter mode property

[Pekka Paalanen]

On Tue, 22 Oct 2019 20:48:02 +0530
"Sharma, Shashank" <shashank.sharma at intel.com> wrote:

> Hello Ville,
> 
> Thanks for the comments, mine inline.
> 
> 
> On 10/22/2019 5:50 PM, Ville Syrjälä wrote:
> > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:  
> >> This patch adds a scaling filter mode porperty
> >> to allow:
> >> - A driver/HW to showcase it's scaling filter capabilities.
> >> - A userspace to pick a desired effect while scaling.
> >>
> >> This option will be particularly useful in the scenarios where
> >> Integer mode scaling is possible, and a UI client wants to pick
> >> filters like Nearest-neighbor applied for non-blurry outputs.
> >>
> >> There was a RFC patch series published, to discus the request to enable
> >> Integer mode scaling by some of the gaming communities, which can be
> >> found here:
> >> https://patchwork.freedesktop.org/series/66175/
> >>
> >> Signed-off-by: Shashank Sharma <shashank.sharma at intel.com>
> >> ---
> >>   drivers/gpu/drm/drm_atomic_uapi.c |  4 ++++
> >>   include/drm/drm_crtc.h            | 26 ++++++++++++++++++++++++++
> >>   include/drm/drm_mode_config.h     |  6 ++++++
> >>   3 files changed, 36 insertions(+)

...

> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> index 5e9b15a0e8c5..94c5509474a8 100644
> >> --- a/include/drm/drm_crtc.h
> >> +++ b/include/drm/drm_crtc.h
> >> @@ -58,6 +58,25 @@ struct device_node;
> >>   struct dma_fence;
> >>   struct edid;
> >>   
> >> +enum drm_scaling_filters {
> >> +	DRM_SCALING_FILTER_DEFAULT,
> >> +	DRM_SCALING_FILTER_MEDIUM,
> >> +	DRM_SCALING_FILTER_BILINEAR,
> >> +	DRM_SCALING_FILTER_NN,  
> > Please use real words.  
> Yes, I saw that coming. It was getting difficult with the 80 char stuff, 
> it was even more difficult while using it :). But let me see how better 
> can I do here.
> >> +	DRM_SCALING_FILTER_NN_IS_ONLY,  
> > Not a big fan of this. I'd just add the explicit nearest filter
> > and leave the decision whether to use it to userspace.  
> Agree, that's also one option. I was thinking to make it convenient for 
> userspace,  For example if a compositor just want to checkout NN only 
> when its beneficial (like old gaming scenarios) but doesn't have enough 
> information (or intent), it can leave it to kernel too. But I agree, 
> this can cause corner cases. Let's discuss and see if we need it at all, 
> as you mentioned.

Hi,

how could the kernel have more information or knowledge of intent than
a display server? I cannot see how, because everything the kernel gets
comes through the display server.

I agree with Ville here.


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/dri-devel/attachments/20191023/b227e4c2/attachment.sig>