On Tue, 22 Oct 2019 20:48:02 +0530 "Sharma, Shashank" <shashank.sharma@xxxxxxxxx> 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@xxxxxxxxx> > >> --- > >> 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
Attachment:
pgpvCQghN2c_d.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
